RE: Flushing data cache on PPC405 in Linux
-Original Message- From: Dan Malek [mailto:ppc6...@digitaldans.com] Sent: Wednesday, February 23, 2011 8:39 PM To: John Linn Cc: linuxppc-...@ozlabs.org Subject: Re: Flushing data cache on PPC405 in Linux Hi John. On Feb 23, 2011, at 5:04 PM, John Linn wrote: Any thoughts? I can come up with two methods, but before I describe them ensure you consider the actual implementation of your 405 core. My comments are based on the standard ppc405 processor, but since you can configure the embedded cores to your liking, the cache size may be different that the 16K bytes on the old processor. Method one. Just 'memset()' 16K of data that will replace all cache lines and push out modified lines. This 16K must be physically contiguous, so allocate in your favorite way, with with the cache coherent DMA functions, bootmem, reserved, whatever. Just ensure that this 16K is also cached, as I've implemented dma_cache_coherent into uncached VM space in the past :-) Awesome Dan, that seems reasonable to me and much easier than I was thinking :) I was obviously making it harder than it had to be as usual. Seems like I can just kmalloc the memory then memset it. Appreciate the help and suggestions. -- John Method two. Use 'dcread' to read the cache tags. If the line is modified, form an EA that will match that line and 'dcbf' the line. This is a little more tricky because the tags are physical addresses, so you would need to do this with the MMU disabled to ensure the physical EA you generated also hits the cache. The upside is you only perform the actual required flush operations, and you didn't blow the cache away requiring a refill latency. Have fun! -- Dan This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Flushing data cache on PPC405 in Linux
-Original Message- From: John Linn Sent: Thursday, February 24, 2011 7:15 AM To: 'Dan Malek' Cc: linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca Subject: RE: Flushing data cache on PPC405 in Linux -Original Message- From: Dan Malek [mailto:ppc6...@digitaldans.com] Sent: Wednesday, February 23, 2011 8:39 PM To: John Linn Cc: linuxppc-...@ozlabs.org Subject: Re: Flushing data cache on PPC405 in Linux Hi John. On Feb 23, 2011, at 5:04 PM, John Linn wrote: Any thoughts? I can come up with two methods, but before I describe them ensure you consider the actual implementation of your 405 core. My comments are based on the standard ppc405 processor, but since you can configure the embedded cores to your liking, the cache size may be different that the 16K bytes on the old processor. Method one. Just 'memset()' 16K of data that will replace all cache lines and push out modified lines. This 16K must be physically contiguous, so allocate in your favorite way, with with the cache coherent DMA functions, bootmem, reserved, whatever. Just ensure that this 16K is also cached, as I've implemented dma_cache_coherent into uncached VM space in the past :-) Awesome Dan, that seems reasonable to me and much easier than I was thinking :) I was obviously making it harder than it had to be as usual. Seems like I can just kmalloc the memory then memset it. It seems like this also depends on that fact that __GFP_COLD will work, otherwise some of the data could already be in the cache such that you're not guaranteed to get everything out of the cache. Do we know that works on arch/powerpc, or I'm not understanding it right? I'm doing some digging to make sure. Thanks, John Appreciate the help and suggestions. -- John Method two. Use 'dcread' to read the cache tags. If the line is modified, form an EA that will match that line and 'dcbf' the line. This is a little more tricky because the tags are physical addresses, so you would need to do this with the MMU disabled to ensure the physical EA you generated also hits the cache. The upside is you only perform the actual required flush operations, and you didn't blow the cache away requiring a refill latency. Have fun! -- Dan This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Flushing data cache on PPC405 in Linux
I have a situation that requires a flush the data cache at specific time periods to help with memory scrubbing. On the 405, I don't see any easy way to do this since you don't know what the cache has in it and there's not an instruction to flush the whole cache. It looks like a kernel driver is needed to map pages then flush that data cache for the pages. I'm concerned there will be side affects I don't realize as I'm assuming the driver would slowly go thru all of physical memory mapping pages (cached or non-cached) and then flushing all addresses in the page(s). Any thoughts? Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] net: ll_temac: fix checksum offload logic
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Wednesday, May 26, 2010 9:45 PM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; Brian Hill Subject: Re: [PATCH 2/2] net: ll_temac: fix checksum offload logic aFrom: John Linn john.l...@xilinx.com Date: Wed, 26 May 2010 11:29:19 -0600 The current checksum offload code does not work and this corrects that functionality. It also updates the interrupt coallescing initialization so than there are fewer interrupts and performance is increased. Signed-off-by: Brian Hill brian.h...@xilinx.com Signed-off-by: John Linn john.l...@xilinx.com Applied, although I changed temac_features to be explicitly unsigned int instead of just plain unsigned Awesome! Appreciate the help with both patches David. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] net: ll_temac: fix checksum offload logic
The current checksum offload code does not work and this corrects
that functionality. It also updates the interrupt coallescing
initialization so than there are fewer interrupts and performance
is increased.
Signed-off-by: Brian Hill brian.h...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/net/ll_temac.h |5 +++
drivers/net/ll_temac_main.c | 82 ++
2 files changed, 63 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index c033584..2e0c9cc 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -295,6 +295,10 @@ This option defaults to enabled (set) */
#define MULTICAST_CAM_TABLE_NUM 4
+/* TEMAC Synthesis features */
+#define TEMAC_FEATURE_RX_CSUM (1 0)
+#define TEMAC_FEATURE_TX_CSUM (1 1)
+
/* TX/RX CURDESC_PTR points to first descriptor */
/* TX/RX TAILDESC_PTR points to last descriptor in linked list */
@@ -353,6 +357,7 @@ struct temac_local {
struct mutex indirect_mutex;
u32 options;/* Current options word */
int last_link;
+ unsigned temac_features;
/* Buffer descriptors */
struct cdmac_bd *tx_bd_v;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 0615737..52dcc84 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -245,7 +245,7 @@ static int temac_dma_bd_init(struct net_device *ndev)
CHNL_CTRL_IRQ_COAL_EN);
/* 0x10220483 */
/* 0x00100483 */
- lp-dma_out(lp, RX_CHNL_CTRL, 0xff01 |
+ lp-dma_out(lp, RX_CHNL_CTRL, 0xff07 |
CHNL_CTRL_IRQ_EN |
CHNL_CTRL_IRQ_DLY_EN |
CHNL_CTRL_IRQ_COAL_EN |
@@ -574,6 +574,10 @@ static void temac_start_xmit_done(struct net_device *ndev)
if (cur_p-app4)
dev_kfree_skb_irq((struct sk_buff *)cur_p-app4);
cur_p-app0 = 0;
+ cur_p-app1 = 0;
+ cur_p-app2 = 0;
+ cur_p-app3 = 0;
+ cur_p-app4 = 0;
ndev-stats.tx_packets++;
ndev-stats.tx_bytes += cur_p-len;
@@ -589,6 +593,29 @@ static void temac_start_xmit_done(struct net_device *ndev)
netif_wake_queue(ndev);
}
+static inline int temac_check_tx_bd_space(struct temac_local *lp, int num_frag)
+{
+ struct cdmac_bd *cur_p;
+ int tail;
+
+ tail = lp-tx_bd_tail;
+ cur_p = lp-tx_bd_v[tail];
+
+ do {
+ if (cur_p-app0)
+ return NETDEV_TX_BUSY;
+
+ tail++;
+ if (tail = TX_BD_NUM)
+ tail = 0;
+
+ cur_p = lp-tx_bd_v[tail];
+ num_frag--;
+ } while (num_frag = 0);
+
+ return 0;
+}
+
static int temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct temac_local *lp = netdev_priv(ndev);
@@ -603,7 +630,7 @@ static int temac_start_xmit(struct sk_buff *skb, struct
net_device *ndev)
start_p = lp-tx_bd_p + sizeof(*lp-tx_bd_v) * lp-tx_bd_tail;
cur_p = lp-tx_bd_v[lp-tx_bd_tail];
- if (cur_p-app0 STS_CTRL_APP0_CMPLT) {
+ if (temac_check_tx_bd_space(lp, num_frag)) {
if (!netif_queue_stopped(ndev)) {
netif_stop_queue(ndev);
return NETDEV_TX_BUSY;
@@ -613,29 +640,14 @@ static int temac_start_xmit(struct sk_buff *skb, struct
net_device *ndev)
cur_p-app0 = 0;
if (skb-ip_summed == CHECKSUM_PARTIAL) {
- const struct iphdr *ip = ip_hdr(skb);
- int length = 0, start = 0, insert = 0;
-
- switch (ip-protocol) {
- case IPPROTO_TCP:
- start = sizeof(struct iphdr) + ETH_HLEN;
- insert = sizeof(struct iphdr) + ETH_HLEN + 16;
- length = ip-tot_len - sizeof(struct iphdr);
- break;
- case IPPROTO_UDP:
- start = sizeof(struct iphdr) + ETH_HLEN;
- insert = sizeof(struct iphdr) + ETH_HLEN + 6;
- length = ip-tot_len - sizeof(struct iphdr);
- break;
- default:
- break;
- }
- cur_p-app1 = ((start 16) | insert);
- cur_p-app2 = csum_tcpudp_magic(ip-saddr, ip-daddr,
- length, ip-protocol, 0);
- skb-data[insert] = 0;
- skb-data[insert + 1] = 0;
+ unsigned int csum_start_off = skb_transport_offset(skb);
+ unsigned int csum_index_off = csum_start_off + skb-csum_offset;
+
+ cur_p-app0 |= 1; /* TX Checksum Enabled */
+ cur_p-app1
[PATCH 1/2] net: ll_temac: fix interrupt bug when interrupt 0 is used
The code is not checking the interrupt for DMA correctly so that an
interrupt number of 0 will cause a false error.
Signed-off-by: Brian Hill brian.h...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/net/ll_temac_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index fa7620e..0615737 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -950,7 +950,7 @@ temac_of_probe(struct of_device *op, const struct
of_device_id *match)
lp-rx_irq = irq_of_parse_and_map(np, 0);
lp-tx_irq = irq_of_parse_and_map(np, 1);
- if (!lp-rx_irq || !lp-tx_irq) {
+ if ((lp-rx_irq == NO_IRQ) || (lp-tx_irq == NO_IRQ)) {
dev_err(op-dev, could not determine irqs\n);
rc = -ENOMEM;
goto nodev;
--
1.6.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] [V5] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Tuesday, April 13, 2010 2:34 AM To: grant.lik...@secretlab.ca Cc: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; jwbo...@linux.vnet.ibm.com; eric.duma...@gmail.com; john.willi...@petalogix.com; michal.si...@petalogix.com; jty...@cs.ucr.edu Subject: Re: [PATCH 2/2] [V5] Add non-Virtex5 support for LL TEMAC driver From: Grant Likely grant.lik...@secretlab.ca Date: Fri, 9 Apr 2010 12:10:21 -0 On Thu, Apr 8, 2010 at 11:08 AM, John Linn john.l...@xilinx.com wrote: This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com Picked up and build tested both patches on 405, 440, 60x and ppc64. No build problems found either built-in or as a module. for both: Acked-by: Grant Likely grant.lik...@secretlab.ca Ok, both applied to net-next-2.6, thanks everyone for sorting this out. Great! Thanks David, appreciate the help. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] net: ll_temac: remove virt_to_bus call
The virt_to_bus call should not be used any longer as it's considered illegal. The driver has the physical address of the buffer in the descriptor such that it's not necessary anyway. Signed-off-by: John Linn john.l...@xilinx.com --- drivers/net/ll_temac_main.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c index ba617e3..ce9aa78 100644 --- a/drivers/net/ll_temac_main.c +++ b/drivers/net/ll_temac_main.c @@ -612,7 +612,6 @@ static void ll_temac_recv(struct net_device *ndev) struct cdmac_bd *cur_p; dma_addr_t tail_p; int length; - unsigned long skb_vaddr; unsigned long flags; spin_lock_irqsave(lp-rx_lock, flags); @@ -626,8 +625,7 @@ static void ll_temac_recv(struct net_device *ndev) skb = lp-rx_skb[lp-rx_bd_ci]; length = cur_p-app4 0x3FFF; - skb_vaddr = virt_to_bus(skb-data); - dma_unmap_single(ndev-dev.parent, skb_vaddr, length, + dma_unmap_single(ndev-dev.parent, cur_p-phys, length, DMA_FROM_DEVICE); skb_put(skb, length); -- 1.6.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] [V5] Add non-Virtex5 support for LL TEMAC driver
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow the driver
to work on MicroBlaze.
V3 - Only updated it to apply to head, minor change to include slab.h. Also
verified that it now builds for MicroBlaze. Retested on PowerPC and MicroBlaze.
V4 - Removed buffer alignment for skb and called the network functions that
already do the alignment for cache line and word alignment. Added constants
to MicroBlaze system to make sure network alignment is maintained. Also updated
the Kconfig so it depends on Microblaze or PPC based on Grant's comment.
V5 - Respun the patch on top of a new patch to the driver which removed the
call to virt_to_bus as it's now illegal and caused a failure when building
the driver in linux-next. Retested with 440, 405 and Microblaze.
Grant, can you do a build test to verify no build issues?
---
arch/microblaze/include/asm/system.h | 11 +++
drivers/net/Kconfig |2 +-
drivers/net/ll_temac.h | 14 +++-
drivers/net/ll_temac_main.c | 137 +
4 files changed, 126 insertions(+), 38 deletions(-)
diff --git a/arch/microblaze/include/asm/system.h
b/arch/microblaze/include/asm/system.h
index 59efb3f..48c4f03 100644
--- a/arch/microblaze/include/asm/system.h
+++ b/arch/microblaze/include/asm/system.h
@@ -12,6 +12,7 @@
#include asm/registers.h
#include asm/setup.h
#include asm/irqflags.h
+#include asm/cache.h
#include asm-generic/cmpxchg.h
#include asm-generic/cmpxchg-local.h
@@ -96,4 +97,14 @@ extern struct dentry *of_debugfs_root;
#define arch_align_stack(x) (x)
+/*
+ * MicroBlaze doesn't handle unaligned accesses in hardware.
+ *
+ * Based on this we force the IP header alignment in network drivers.
+ * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
+ * cacheline alignment of buffers.
+ */
+#define NET_IP_ALIGN 2
+#define NET_SKB_PADL1_CACHE_BYTES
+
#endif /* _ASM_MICROBLAZE_SYSTEM_H */
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7b832c7..9073741 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2434,8 +2434,8 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver
+ depends on PPC || MICROBLAZE
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..c033584 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of Ethernet header */
@@ -290,9 +293,6 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
-#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
-
#define MULTICAST_CAM_TABLE_NUM 4
/* TX/RX CURDESC_PTR points to first descriptor */
@@ -335,9 +335,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index ce9aa78..2b69d6c 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -116,17 +113,86 @@ void temac_indirect_out32(struct temac_local *lp, int
reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Tuesday, April 06, 2010 8:52 PM To: eric.duma...@gmail.com Cc: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; jty...@cs.ucr.edu Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver From: Eric Dumazet eric.duma...@gmail.com Date: Mon, 05 Apr 2010 23:29:53 +0200 So, I ask, cant you use netdev_alloc_skb_ip_align() in this driver ? Thanks to everyone for getting this patch into shape. I applied version 4 of the patch to net-next-2.6, thanks! Thanks David, appreciate everyone's help and patience. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Monday, April 05, 2010 3:30 PM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le lundi 05 avril 2010 à 15:11 -0600, John Linn a écrit : This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Very interesting way of doing this, but why such convoluted thing ? This is trying to align for a cache line (32 bytes) before my change. My change was then also making it align the IP data on a word boundary. Because of the % 32, this is equivalent to : #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) Yes, but I'm not sure that's clearer IMHO. But wait, dont we recognise the magic constant NET_IP_ALIGN ? Yes it could be used. I'm struggling with how to make this all be clearer. How about this? #define BUFFER_ALIGN(adr) (((XTE_ALIGN + NET_IP_ALIGN) - ((u32) adr)) % XTE_ALIGN) So, I ask, cant you use netdev_alloc_skb_ip_align() in this driver ? From what I can tell, this wouldn't work as it only reserves the 2 bytes to align with a word boundary. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Tuesday, April 06, 2010 11:01 AM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le mardi 06 avril 2010 à 10:12 -0600, John Linn a écrit : -Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Monday, April 05, 2010 3:30 PM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le lundi 05 avril 2010 à 15:11 -0600, John Linn a écrit : This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Very interesting way of doing this, but why such convoluted thing ? This is trying to align for a cache line (32 bytes) before my change. My change was then also making it align the IP data on a word boundary. Because of the % 32, this is equivalent to : #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) Yes, but I'm not sure that's clearer IMHO. But wait, dont we recognise the magic constant NET_IP_ALIGN ? Yes it could be used. I'm struggling with how to make this all be clearer. I am not saying its clearer, I am saying we have a standard way to handle this exact problem (aligning rcvs buffer so that IP header is aligned) There is no need to invent new ones, this makes reviewing of this driver more difficult. How about this? #define BUFFER_ALIGN(adr) (((XTE_ALIGN + NET_IP_ALIGN) - ((u32) adr)) % XTE_ALIGN) Sorry, I still dont understand why you need XTE_ALIGN + ... ((A + B) - C) % A is equal to (B - C) % A Which one is more readable ? I'm fine with your suggestion. #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) Please take a look at existing and clean code, no magic macro, and we can understand the intention. find drivers/net | xargs grep -n netdev_alloc_skb_ip_align Yes I see how it's used, but it only allows you to reserve 2 bytes in the skb with no options. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Tuesday, April 06, 2010 12:54 PM To: John Linn Cc: Eric Dumazet; net...@vger.kernel.org; linuxppc-...@ozlabs.org; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver On Tue, Apr 6, 2010 at 11:11 AM, John Linn john.l...@xilinx.com wrote: -Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Tuesday, April 06, 2010 11:01 AM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le mardi 06 avril 2010 à 10:12 -0600, John Linn a écrit : -Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Monday, April 05, 2010 3:30 PM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le lundi 05 avril 2010 à 15:11 -0600, John Linn a écrit : This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Very interesting way of doing this, but why such convoluted thing ? This is trying to align for a cache line (32 bytes) before my change. My change was then also making it align the IP data on a word boundary. Because of the % 32, this is equivalent to : #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) Yes, but I'm not sure that's clearer IMHO. But wait, dont we recognise the magic constant NET_IP_ALIGN ? Yes it could be used. I'm struggling with how to make this all be clearer. I am not saying its clearer, I am saying we have a standard way to handle this exact problem (aligning rcvs buffer so that IP header is aligned) There is no need to invent new ones, this makes reviewing of this driver more difficult. Hold on BUFFER_ALIGN is being used to align the DMA buffer on a cache line boundary. I don't think netdev_alloc_skb() makes any guarantees about how the start of the IP header lines up against cache line boundaries. The amount of padding needed is not known until an skbuff is obtained from netdev_alloc_skb(), and netdev_alloc_skb_ip_align() can only handle a fixed size padding, It doesn't look like netdev_alloc_skb_ip_align() is the right thing in this regard. How about this? #define BUFFER_ALIGN(adr) (((XTE_ALIGN + NET_IP_ALIGN) - ((u32) adr)) % XTE_ALIGN) Sorry, I still dont understand why you need XTE_ALIGN + ... ((A + B) - C) % A is equal to (B - C) % A Which one is more readable ? I'm fine with your suggestion. #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) Please take a look at existing and clean code, no magic macro, and we can understand the intention. find drivers/net | xargs grep -n netdev_alloc_skb_ip_align Yes I see how it's used, but it only allows you to reserve 2 bytes in the skb with no options. Eric is here. The mod operation means that BUFFER_ALIGN using either 2 or 34 is equivalent. g. I can spin another patch with the following and with Grant's Kconfig changes, just looking for confirmation that's acceptable. #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Steven J. Magnani [mailto:st...@digidescorp.com] Sent: Tuesday, April 06, 2010 2:04 PM To: grant.lik...@secretlab.ca Cc: John Linn; Eric Dumazet; net...@vger.kernel.org; linuxppc-...@ozlabs.org; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver On Tue, 2010-04-06 at 12:53 -0600, Grant Likely wrote: Hold on BUFFER_ALIGN is being used to align the DMA buffer on a cache line boundary. I don't think netdev_alloc_skb() makes any guarantees about how the start of the IP header lines up against cache line boundaries. The amount of padding needed is not known until an skbuff is obtained from netdev_alloc_skb(), and netdev_alloc_skb_ip_align() can only handle a fixed size padding, It doesn't look like netdev_alloc_skb_ip_align() is the right thing in this regard. __netdev_alloc_skb reserves NET_SKB_PAD bytes which gets us cacheline alignment on Microblaze. From include/linux/skbuff.h: Good find. I'll give it a test on MicroBlaze and PowerPC. /* * The networking layer reserves some headroom in skb data (via * dev_alloc_skb). This is used to avoid having to reallocate skb data when * the header has to grow. In the default case, if the header has to grow * 32 bytes or less we avoid the reallocation. * * Unfortunately this headroom changes the DMA alignment of the resulting * network packet. As for NET_IP_ALIGN, this unaligned DMA is expensive * on some architectures. An architecture can override this value, * perhaps setting it to a cacheline in size (since that will maintain * cacheline alignment of the DMA). It must be a power of 2. * * Various parts of the networking layer expect at least 32 bytes of * headroom, you should not reduce this. */ #ifndef NET_SKB_PAD #define NET_SKB_PAD 32 #endif If this doesn't work for some of the PPC variants with larger cache lines, maybe one of the PPC header files needs to define NET_SKB_PAD? Looks like it is defined in system.h in powerpc so that it works. And if we want to guard against possible future changes to the default NET_SKB_PAD breaking Microblaze operation, maybe one of its headers should define NET_SKB_PAD as well? Good idea, we can add that to system.h for MicroBlaze also. Thanks, John Steven J. Magnani I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator! #include standard.disclaimer This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Tuesday, April 06, 2010 2:24 PM To: grant.lik...@secretlab.ca Cc: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le mardi 06 avril 2010 à 12:53 -0600, Grant Likely a écrit : Hold on BUFFER_ALIGN is being used to align the DMA buffer on a cache line boundary. I don't think netdev_alloc_skb() makes any guarantees about how the start of the IP header lines up against cache line boundaries. The amount of padding needed is not known until an skbuff is obtained from netdev_alloc_skb(), and netdev_alloc_skb_ip_align() can only handle a fixed size padding, It doesn't look like netdev_alloc_skb_ip_align() is the right thing in this regard. OK, time to have a long explanation : netdev_alloc_skb_ip_align() is doing the right thing, but it seems you guys insist to invent a new private stuff. I am only wondering if you really know why you do this. Many drivers do have same requirements, so every driver should reinvent the wheel ? Really this is beyond me. Original code was aligning the buffer on a 32 bytes boundary (because of a hardware requirement on NIC, I only trust original code on this). Then you want to change this to align buffer on this 32 bytes boundary PLUS 2. What is this kind of new requirement ? 1) Hardware requirement really changed that much. (firmware changed on NIC). If not using this new alignement, NIC doesnt work at all. 2) or Microblaze arch requires that IP header is aligned on a word boundary to avoid unaligned traps in IP stack ? (like many arches) Yes. If this is the latest requirement, then use standard mechanism. skb data is naturally aligned on L1_CACHE_SIZE + SKB_PAD boundaries. (32 bytes alignment) netdev_alloc_skb_ip_align()() then skips 2 bytes to make skb data aligned so that 2 + 14 (sizeof eth header) = 16 : IP header is aligned (modulo 16) It just works. If not, we should correct it, please fill a bug report. Trying it now, thanks for the help and patience :) -- John Thanks This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [V4] Add non-Virtex5 support for LL TEMAC driver
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow the driver
to work on MicroBlaze.
V3 - Only updated it to apply to head, minor change to include slab.h. Also
verified that it now builds for MicroBlaze. Retested on PowerPC and MicroBlaze.
V4 - Removed buffer alignment for skb and called the network functions that
already do the alignment for cache line and word alignment. Added constants
to MicroBlaze system to make sure network alignment is maintained. Also updated
the Kconfig so it depends on Microblaze or PPC based on Grant's comment.
---
arch/microblaze/include/asm/system.h | 11 +++
drivers/net/Kconfig |2 +-
drivers/net/ll_temac.h | 14 +++-
drivers/net/ll_temac_main.c | 137 +
4 files changed, 126 insertions(+), 38 deletions(-)
diff --git a/arch/microblaze/include/asm/system.h
b/arch/microblaze/include/asm/system.h
index 59efb3f..48c4f03 100644
--- a/arch/microblaze/include/asm/system.h
+++ b/arch/microblaze/include/asm/system.h
@@ -12,6 +12,7 @@
#include asm/registers.h
#include asm/setup.h
#include asm/irqflags.h
+#include asm/cache.h
#include asm-generic/cmpxchg.h
#include asm-generic/cmpxchg-local.h
@@ -96,4 +97,14 @@ extern struct dentry *of_debugfs_root;
#define arch_align_stack(x) (x)
+/*
+ * MicroBlaze doesn't handle unaligned accesses in hardware.
+ *
+ * Based on this we force the IP header alignment in network drivers.
+ * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
+ * cacheline alignment of buffers.
+ */
+#define NET_IP_ALIGN 2
+#define NET_SKB_PADL1_CACHE_BYTES
+
#endif /* _ASM_MICROBLAZE_SYSTEM_H */
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ba5b8e..207a57d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2434,8 +2434,8 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver
+ depends on PPC || MICROBLAZE
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..c033584 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of Ethernet header */
@@ -290,9 +293,6 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
-#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
-
#define MULTICAST_CAM_TABLE_NUM 4
/* TX/RX CURDESC_PTR points to first descriptor */
@@ -335,9 +335,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index ba617e3..6270bb0 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -116,17 +113,86 @@ void temac_indirect_out32(struct temac_local *lp, int
reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ return
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Monday, April 05, 2010 1:17 PM To: grant.lik...@secretlab.ca Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; jty...@cs.ucr.edu; John Linn Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver From: Grant Likely grant.lik...@secretlab.ca Date: Mon, 5 Apr 2010 12:10:51 -0600 David, are you going to pick up this patch, or would you like me to? The submitter, when asked, stated that he couldn't even get the driver to build on microblaze against mainline. So I marked the patch changed requested because being able to build is... you know... sort of a requirement for integration. More changes made it into the MicroBlaze mainline and it looks like I need to respin the patch again as there are some minor changes on the top of the tree. It built and ran fine on PowerPc, but not MicroBlaze. I'll check now. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow the driver
to work on MicroBlaze.
V3 - Only updated it to apply to head, minor change to include slab.h. Also
verified that it now builds for MicroBlaze. Retested on PowerPC and MicroBlaze.
---
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124 ++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ba5b8e..17044dc 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2435,7 +2435,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index ba617e3..801b076 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -116,17 +113,86 @@ void temac_indirect_out32(struct temac_local *lp, int
reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ return in_be32((u32 *)(lp-sdma_regs + (reg 2)));
}
+/**
+ * temac_dma_out32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
{
+ out_be32((u32 *)(lp-sdma_regs + (reg 2)), value);
+}
+
+/* DMA register access functions can be DCR based or memory mapped.
+ * The PowerPC 440 is DCR based, the PowerPC 405 and MicroBlaze are both
+ * memory mapped.
+ */
+#ifdef CONFIG_PPC_DCR
+
+/**
+ * temac_dma_dcr_in32 - DCR based DMA read
+ */
+static u32 temac_dma_dcr_in(struct temac_local *lp, int reg)
+{
+ return dcr_read(lp-sdma_dcrs, reg);
+}
+
+/**
+ * temac_dma_dcr_out32 - DCR based DMA write
+ */
+static void temac_dma_dcr_out(struct temac_local *lp, int reg, u32 value)
+{
dcr_write(lp-sdma_dcrs, reg, value);
}
/**
+ * temac_dcr_setup - If the DMA is DCR based, then setup the address and
+ * I/O functions
+ */
+static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
+ struct device_node *np
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Monday, April 05, 2010 1:17 PM To: grant.lik...@secretlab.ca Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; jty...@cs.ucr.edu; John Linn Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver From: Grant Likely grant.lik...@secretlab.ca Date: Mon, 5 Apr 2010 12:10:51 -0600 David, are you going to pick up this patch, or would you like me to? The submitter, when asked, stated that he couldn't even get the driver to build on microblaze against mainline. So I marked the patch changed requested because being able to build is... you know... sort of a requirement for integration. Pushed out V3 of the patch, forgot to copy you David. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Monday, April 05, 2010 3:30 PM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; John Tyner Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Le lundi 05 avril 2010 à 15:11 -0600, John Linn a écrit : This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Very interesting way of doing this, but why such convoluted thing ? Grant might have insight into why this started this way, I just updated to help with MicroBlaze alignment. Because of the % 32, this is equivalent to : #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN) But wait, dont we recognise the magic constant NET_IP_ALIGN ? So, I ask, cant you use netdev_alloc_skb_ip_align() in this driver ? Will have to look at it to better understand, maybe. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through
the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
It was tested on the Xilinx tree for MicroBlaze which is based on the
mainline and the Petalogix tree as DMA was needed. I tried to build
against the mainline head but got errors with the DMA routines. I guess
it's possible that it was a configuration issue there as I didn't dig
real deep.
I tested the PowerPC against the head of mainline.
Thanks,
John
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow
the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124
++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC)
driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of
Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c
b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the
driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -115,17 +112,86 @@ void temac_indirect_out32(struct temac_local
*lp, int reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ return in_be32((u32 *)(lp-sdma_regs + (reg 2)));
}
+/**
+ * temac_dma_out32 - Memory mapped DMA read, this function expects
a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static void temac_dma_out32(struct temac_local *lp, int reg, u32
value)
{
+ out_be32((u32 *)(lp-sdma_regs + (reg 2)), value
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 8:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC
driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft
DMA
registers as if they were memory mapped instead of solely through
the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the
MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
It was tested on the Xilinx tree for MicroBlaze which is based on
the
mainline and the Petalogix tree as DMA was needed. I tried to build
against the mainline head but got errors with the DMA routines. I
guess
it's possible that it was a configuration issue there as I didn't
dig
real deep.
New dma api is in for-linus branch.
I tested it on that version and I am seeing some weird things. :-(
Access to bad area. I will try your tree.
The second thing which I see is in ll_temac_recv function.
On the following line is read a packet length which could be 0-16k.
length = cur_p-app4 0x3FFF;
But allocated skb has max size XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What happen if driver get packet greater than 9kB?
I got it (I don't know how) but skb_put has one checking mechanism
which
will cal skb_over_panic which caused panic.
That's the whole reason for that panic to me and when I got it in the
past and looked it up it made sense to me. I personally don't see a
good reason to check for it in the driver since the kernel catches it,
but maybe others do.
Thanks,
John
That's why I think that will be good always to check that length is
less
than XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What do you think?
Thanks,
Michal
I tested the PowerPC against the head of mainline.
Thanks,
John
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to
allow
the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124
++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC)
driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of
Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as
MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c
b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Stephen Neuendorffer Sent: Monday, March 15, 2010 11:03 AM To: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com Cc: michal.si...@petalogix.com; John Tyner; john.willi...@petalogix.com Subject: RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver -Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of John Linn Sent: Friday, March 12, 2010 5:06 PM To: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com Cc: michal.si...@petalogix.com; John Tyner; John Linn; john.willi...@petalogix.com Subject: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- V2 - Incorporated comments from Grant and added more logic to allow the driver to work on MicroBlaze. drivers/net/Kconfig |1 - drivers/net/ll_temac.h | 17 +- drivers/net/ll_temac_main.c | 124 ++- 3 files changed, 113 insertions(+), 29 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 9b6efe1..5402105 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2443,7 +2443,6 @@ config MV643XX_ETH config XILINX_LL_TEMAC tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver select PHYLIB - depends on PPC_DCR_NATIVE help This driver supports the Xilinx 10/100/1000 LocalLink TEMAC core used in Xilinx Spartan and Virtex FPGAs diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h index 1af66a1..915aa34 100644 --- a/drivers/net/ll_temac.h +++ b/drivers/net/ll_temac.h @@ -5,8 +5,11 @@ #include linux/netdevice.h #include linux/of.h #include linux/spinlock.h + +#ifdef CONFIG_PPC_DCR #include asm/dcr.h #include asm/dcr-regs.h +#endif /* packet size info */ #define XTE_HDR_SIZE 14 /* size of Ethernet header */ @@ -290,8 +293,12 @@ This option defaults to enabled (set) */ #define TX_CONTROL_CALC_CSUM_MASK 1 +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Is '34' really XTE_ALIGN + 2? (I really have no idea it just looks like a suspicious change.) Steve Valid point that it is XTE_ALIGN + 2. As the comment says, it aligns the IP data in the packet. -- John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124 ++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -115,17 +112,86 @@ void temac_indirect_out32(struct temac_local *lp, int
reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ return in_be32((u32 *)(lp-sdma_regs + (reg 2)));
}
+/**
+ * temac_dma_out32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
{
+ out_be32((u32 *)(lp-sdma_regs + (reg 2)), value);
+}
+
+/* DMA register access functions can be DCR based or memory mapped.
+ * The PowerPC 440 is DCR based, the PowerPC 405 and MicroBlaze are both
+ * memory mapped.
+ */
+#ifdef CONFIG_PPC_DCR
+
+/**
+ * temac_dma_dcr_in32 - DCR based DMA read
+ */
+static u32 temac_dma_dcr_in(struct temac_local *lp, int reg)
+{
+ return dcr_read(lp-sdma_dcrs, reg);
+}
+
+/**
+ * temac_dma_dcr_out32 - DCR based DMA write
+ */
+static void temac_dma_dcr_out(struct temac_local *lp, int reg, u32 value)
+{
dcr_write(lp-sdma_dcrs, reg, value);
}
/**
+ * temac_dcr_setup - If the DMA is DCR based, then setup the address and
+ * I/O functions
+ */
+static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
+ struct device_node *np)
+{
+ unsigned int dcrs;
+
+ /* setup the dcr address mapping if it's in the device tree */
+
+ dcrs = dcr_resource_start(np, 0);
+ if (dcrs
Proposal to move PCI out of arch/powerpc and into drivers/of
Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PCI NIC for powerpc system
Hi, I should apologize ahead of time for my lack of knowledge with PCI. I'm trying to better understand if I can run a standard off the shelf PCI NIC with a powerpc kernel as the PCI with device tree is not clear to me. I don't see many Ethernet drivers having OF support in them so maybe devices on the PCI bus are discovered by the kernel such that the drivers don't need to be OF aware. Any advice is appreciated. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [V3] net: emaclite: adding MDIO and phy lib support
These changes add MDIO and phy lib support to the driver as the
IP core now supports the MDIO bus.
The MDIO bus and phy are added as a child to the emaclite in the device
tree as illustrated below.
mdio {
#address-cells = 1;
#size-cells = 0;
phy0: p...@7 {
compatible = marvell,88e;
reg = 7;
} ;
}
Signed-off-by: Sadanand Mutyala sadanand.muty...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
V2 - updated it for Grant's comments, except I couldn't find any tabs
converted to white space issue, let's see if V2 has it also
V3 - updated it for Grant's comments, aded mutex release when a timeout
happens, and added Grant's acked by.
---
drivers/net/Kconfig |1 +
drivers/net/xilinx_emaclite.c | 399 -
2 files changed, 357 insertions(+), 43 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index dd9a09c..9509a36 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1939,6 +1939,7 @@ config ATL2
config XILINX_EMACLITE
tristate Xilinx 10/100 Ethernet Lite support
depends on PPC32 || MICROBLAZE
+ select PHYLIB
help
This driver supports the 10/100 Ethernet Lite from Xilinx.
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 8c777ba..feed72d 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -22,11 +22,17 @@
#include linux/of_device.h
#include linux/of_platform.h
+#include linux/of_mdio.h
+#include linux/phy.h
#define DRIVER_NAME xilinx_emaclite
/* Register offsets for the EmacLite Core */
#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
+#define XEL_MDIOADDR_OFFSET0x07E4 /* MDIO Address Register */
+#define XEL_MDIOWR_OFFSET 0x07E8 /* MDIO Write Data Register */
+#define XEL_MDIORD_OFFSET 0x07EC /* MDIO Read Data Register */
+#define XEL_MDIOCTRL_OFFSET0x07F0 /* MDIO Control Register */
#define XEL_GIER_OFFSET0x07F8 /* GIE Register */
#define XEL_TSR_OFFSET 0x07FC /* Tx status */
#define XEL_TPLR_OFFSET0x07F4 /* Tx packet length */
@@ -37,6 +43,22 @@
#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset */
+/* MDIO Address Register Bit Masks */
+#define XEL_MDIOADDR_REGADR_MASK 0x001F /* Register Address */
+#define XEL_MDIOADDR_PHYADR_MASK 0x03E0 /* PHY Address */
+#define XEL_MDIOADDR_PHYADR_SHIFT 5
+#define XEL_MDIOADDR_OP_MASK 0x0400/* RD/WR Operation */
+
+/* MDIO Write Data Register Bit Masks */
+#define XEL_MDIOWR_WRDATA_MASK 0x/* Data to be Written */
+
+/* MDIO Read Data Register Bit Masks */
+#define XEL_MDIORD_RDDATA_MASK 0x/* Data to be Read */
+
+/* MDIO Control Register Bit Masks */
+#define XEL_MDIOCTRL_MDIOSTS_MASK 0x0001 /* MDIO Status Mask */
+#define XEL_MDIOCTRL_MDIOEN_MASK 0x0008 /* MDIO Enable */
+
/* Global Interrupt Enable Register (GIER) Bit Masks */
#define XEL_GIER_GIE_MASK 0x8000 /* Global Enable */
@@ -87,6 +109,13 @@
* @reset_lock:lock used for synchronization
* @deferred_skb: holds an skb (for transmission at a later time) when the
* Tx buffer is not free
+ * @phy_dev: pointer to the PHY device
+ * @phy_node: pointer to the PHY device node
+ * @mii_bus: pointer to the MII bus
+ * @mdio_irqs: IRQs table for MDIO bus
+ * @last_link: last link status
+ * @has_mdio: indicates whether MDIO is included in the HW
+ * @mdio_mutex:protects MDIO accesses
*/
struct net_local {
@@ -100,6 +129,16 @@ struct net_local {
spinlock_t reset_lock;
struct sk_buff *deferred_skb;
+
+ struct phy_device *phy_dev;
+ struct device_node *phy_node;
+
+ struct mii_bus *mii_bus;
+ int mdio_irqs[PHY_MAX_ADDR];
+
+ int last_link;
+ bool has_mdio;
+ struct mutex mdio_mutex;
};
@@ -431,7 +470,7 @@ static u16 xemaclite_recv_data(struct net_local *drvdata,
u8 *data)
}
/**
- * xemaclite_set_mac_address - Set the MAC address for this device
+ * xemaclite_update_address - Update the MAC address in the device
* @drvdata: Pointer to the Emaclite device private data
* @address_ptr:Pointer to the MAC address (MAC address is a 48-bit value)
*
@@ -441,8 +480,8 @@ static u16 xemaclite_recv_data(struct net_local *drvdata,
u8 *data)
* The MAC address can be programmed using any of the two transmit
* buffers (if configured).
*/
-static void xemaclite_set_mac_address(struct net_local *drvdata,
- u8 *address_ptr)
+static void xemaclite_update_address(struct net_local *drvdata,
+u8
RE: [PATCH] [V3] net: emaclite: adding MDIO and phy lib support
-Original Message-
From: John Williams [mailto:john.willi...@petalogix.com]
Sent: Tuesday, February 09, 2010 3:30 PM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; Sadanand Mutyala
Subject: Re: [PATCH] [V3] net: emaclite: adding MDIO and phy lib support
Hi John,
Sorry If I'm painting bike-sheds here, just one tiny tweak might be in
order to standardise your mutex_unlock exit path:
Hey John, I prefer burning down bike-sheds myself, fire and explosions are
always more fun than painting :)
+static int xemaclite_mdio_read(struct mii_bus *bus, int phy_id, int reg)
+{
+ struct net_local *lp = bus-priv;
+ u32 ctrl_reg;
+ u32 rc;
+
+ mutex_lock(lp-mdio_mutex);
+
+ if (xemaclite_mdio_wait(lp)) {
+ mutex_unlock(lp-mdio_mutex);
+ return -ETIMEDOUT;
+ }
[snip]
+ if (xemaclite_mdio_wait(lp)) {
+ mutex_unlock(lp-mdio_mutex);
+ return -ETIMEDOUT;
+ }
[snip]
+ dev_dbg(lp-ndev-dev,
+ xemaclite_mdio_read(phy_id=%i, reg=%x) == %x\n,
+ phy_id, reg, rc);
+
+ return rc;
Can this be better expressed like this:
my_func() {
mutex_lock()
..
if(some error) {
rc=-ETIMEDOUT;
goto out_unlock;
}
...
/* success path */
rc=0;
..
out_unlock:
mutex_unlock()
return rc;
}
Is this style still favoured in driver exit paths?
I considered that and then blew it off (maybe shouldn't have).
If we think it's a more std way to do it then no big deal. I'll see if there
are any other comments before spinning another maybe final patch.
Thanks for the input,
John
Thanks,
John
--
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] net: emaclite: adding MDIO and phy lib support
-Original Message-
From: John Williams [mailto:john.willi...@petalogix.com]
Sent: Tuesday, February 09, 2010 3:30 PM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; Sadanand Mutyala
Subject: Re: [PATCH] [V3] net: emaclite: adding MDIO and phy lib support
Hi John,
Sorry If I'm painting bike-sheds here, just one tiny tweak might be in
order to standardise your mutex_unlock exit path:
+static int xemaclite_mdio_read(struct mii_bus *bus, int phy_id, int reg)
+{
+ struct net_local *lp = bus-priv;
+ u32 ctrl_reg;
+ u32 rc;
+
+ mutex_lock(lp-mdio_mutex);
+
+ if (xemaclite_mdio_wait(lp)) {
+ mutex_unlock(lp-mdio_mutex);
+ return -ETIMEDOUT;
+ }
[snip]
+ if (xemaclite_mdio_wait(lp)) {
+ mutex_unlock(lp-mdio_mutex);
+ return -ETIMEDOUT;
+ }
[snip]
+ dev_dbg(lp-ndev-dev,
+ xemaclite_mdio_read(phy_id=%i, reg=%x) == %x\n,
+ phy_id, reg, rc);
+
+ return rc;
Can this be better expressed like this:
my_func() {
mutex_lock()
..
if(some error) {
rc=-ETIMEDOUT;
goto out_unlock;
}
...
/* success path */
rc=0;
..
out_unlock:
mutex_unlock()
return rc;
}
Is this style still favoured in driver exit paths?
It looks to me like the mutex is not needed in the driver mdio functions as
there's a mutex in the mdiobus functions already.
Am I wrong about that?
Thanks,
John
From phy/mdio_bus.c
int mdiobus_read(struct mii_bus *bus, int addr, u16 regnum)
{
int retval;
BUG_ON(in_interrupt());
mutex_lock(bus-mdio_lock);
retval = bus-read(bus, addr, regnum);
mutex_unlock(bus-mdio_lock);
return retval;
}
EXPORT_SYMBOL(mdiobus_read);
int mdiobus_write(struct mii_bus *bus, int addr, u16 regnum, u16 val)
{
int err;
BUG_ON(in_interrupt());
mutex_lock(bus-mdio_lock);
err = bus-write(bus, addr, regnum, val);
mutex_unlock(bus-mdio_lock);
return err;
}
EXPORT_SYMBOL(mdiobus_write);
Thanks,
John
--
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V2] net: emaclite: adding MDIO and phy lib support
-Original Message-
From: John Linn [mailto:john.l...@xilinx.com]
Sent: Friday, February 05, 2010 3:41 PM
To: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
jgar...@pobox.com; grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com
Cc: john.willi...@petalogix.com; John Linn; Sadanand Mutyala
Subject: [PATCH] [V2] net: emaclite: adding MDIO and phy lib support
These changes add MDIO and phy lib support to the driver as the
IP core now supports the MDIO bus.
The MDIO bus and phy are added as a child to the emaclite in the
device
tree as illustrated below.
mdio {
#address-cells = 1;
#size-cells = 0;
compatible = xlnx,emaclite-mdio;
phy0: p...@7 {
reg = 7;
} ;
}
Signed-off-by: Sadanand Mutyala sadanand.muty...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - updated it for Grant's comments, except I couldn't find any tabs
converted to white space issue, let's see if V2 has it also
---
drivers/net/Kconfig |1 +
drivers/net/xilinx_emaclite.c | 393
-
2 files changed, 351 insertions(+), 43 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index dd9a09c..9509a36 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1939,6 +1939,7 @@ config ATL2
config XILINX_EMACLITE
tristate Xilinx 10/100 Ethernet Lite support
depends on PPC32 || MICROBLAZE
+ select PHYLIB
help
This driver supports the 10/100 Ethernet Lite from Xilinx.
diff --git a/drivers/net/xilinx_emaclite.c
b/drivers/net/xilinx_emaclite.c
index 8c777ba..02f18dd 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -22,11 +22,17 @@
#include linux/of_device.h
#include linux/of_platform.h
+#include linux/of_mdio.h
+#include linux/phy.h
snip
+static int xemaclite_mdio_read(struct mii_bus *bus, int phy_id, int
reg)
+{
+ struct net_local *lp = bus-priv;
+ u32 ctrl_reg;
+ u32 rc;
+
+ mutex_lock(lp-mdio_mutex);
+
+ if (xemaclite_mdio_wait(lp))
+ return -ETIMEDOUT;
I already see a problem with this patch as when there's a timeout
waiting for the mdio the mutex won't get unlocked. This is true
anywhere the timeout happens (other places also).
I tested it with normal operation, but don't have a great way to test
the timeout paths.
I'll wait for other comments then spin it again to unlock the mutex when
there's a timeout.
Thanks,
John
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] net: emaclite: adding MDIO and phy lib support
-Original Message-
From: Grant Likely
Sent: Thurs, 4 Feb 2010 11:12:29 AM
To: John Linn
Subject: FW: [PATCH] net: emaclite: adding MDIO and phy lib support
Hi John and Sadanand. Looks like a good patch, but a few issues to
resolve. Comments below.
g.
Somehow I didn't get this message but found it out on the web, so this
is a contrived version of the message so I could respond :)
On Wed, Feb 3, 2010 at 5:49 PM, John Linn john.l...@xx
wrote:
These changes add MDIO and phy lib support to the driver as the
IP core now supports the MDIO bus.
The MDIO bus and phy are added as a child to the emaclite in the
device
tree as illustrated below.
mdio {
#address-cells = 1;
#size-cells = 0;
phy0: p...@7 {
reg = 7;
For completeness, phy node need a compatible property.
It seems like this is in the device tree only but the driver won't use
it. So no real affect on the driver unless I'm not synced up with you.
} ;
}
Signed-off-by: Sadanand Mutyala sadanand.muty...@xx
Signed-off-by: John Linn john.l...@xx
---
drivers/net/Kconfig |1 +
drivers/net/xilinx_emaclite.c | 362
-
2 files changed, 319 insertions(+), 44 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 396fd38..2056cd2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1947,6 +1947,7 @@ config ATL2
config XILINX_EMACLITE
tristate Xilinx 10/100 Ethernet Lite support
depends on PPC32 || MICROBLAZE
+ select PHYLIB
help
This driver supports the 10/100 Ethernet Lite from Xilinx.
Patch appears to be whitespace damaged. All tabs have been converted
to spaces.
Ok, will look at this.
snip
+static int xemaclite_mdio_read(struct mii_bus *bus, int phy_id, int
reg)
+{
+ struct net_local *lp = bus-priv;
+ u32 ctrl_reg;
+ u32 rc;
+
+ /* Wait till the device is ready */
+ do {
+ ctrl_reg = in_be32(lp-base_addr +
XEL_MDIOCTRL_OFFSET);
+ } while (ctrl_reg XEL_MDIOCTRL_MDIOSTS_MASK);
This is a busywait loop that just burns cycles while waiting for the
MDIO bus to become non-busy, and further down...
Yep agreed.
+
+ /* Write the PHY address, register number and set the OP bit
in the
+* MDIO Address register. Set the Status bit in the MDIO
Control
+* register to start a MDIO read transaction.
+*/
+ out_be32(lp-base_addr + XEL_MDIOADDR_OFFSET,
+XEL_MDIOADDR_OP_MASK |
+((phy_id XEL_MDIOADDR_PHYADR_SHIFT) | reg));
+ out_be32(lp-base_addr + XEL_MDIOCTRL_OFFSET,
+ctrl_reg | XEL_MDIOCTRL_MDIOSTS_MASK);
+
+ /* Wait for the device to complete the transaction and read
the value
+* from MDIO Read Data register.
+*/
+ do {
+ ctrl_reg = in_be32(lp-base_addr +
XEL_MDIOCTRL_OFFSET);
+ } while (ctrl_reg XEL_MDIOCTRL_MDIOSTS_MASK);
... I see the same thing waiting for the issued transaction to
complete. Busywaiting on slow events, like MDIO transfers, wastes a
lot of cycles that could be used for running other threads.
At the very least, the wait loop should msleep() so that other threads
get scheduled. Even better is if a completion is used and the MDIO
irq can be used to wake up the thread.
Another problem with this busywait is that is has no failure path if
the MDIO bus hangs up. The thread could get stuck spinning on this
loop forever with no way to kill it.
Agree, will fix all these, probably not use an interrupt.
snip
* Return: 0, if the driver is bound to the Emaclite device, or
* a negative error if there is failure.
@@ -853,7 +1104,6 @@ static int __devinit xemaclite_of_probe(struct
of_device *ofdev,
struct net_local *lp = NULL;
struct device *dev = ofdev-dev;
const void *mac_address;
-
Unrelated whitespace change.
Yep.
int rc = 0;
dev_info(dev, Device Tree Probing\n);
@@ -880,6 +1130,7 @@ static int __devinit xemaclite_of_probe(struct
of_device *ofdev,
}
dev_set_drvdata(dev, ndev);
+ SET_NETDEV_DEV(ndev, ofdev-dev);
ndev-irq = r_irq.start;
ndev-mem_start = r_mem.start;
@@ -923,7 +1174,16 @@ static int __devinit xemaclite_of_probe(struct
of_device *ofdev,
out_be32(lp-base_addr + XEL_BUFFER_OFFSET + XEL_TSR_OFFSET,
0);
/* Set the MAC address in the EmacLite device */
- xemaclite_set_mac_address(lp, ndev-dev_addr);
+ xemaclite_update_address(lp, ndev-dev_addr);
+
+ /* Check if MDIO is included in the HW */
+ lp-has_mdio = get_bool(ofdev, xlnx,include-mdio);
+ if (lp-has_mdio) {
+ lp-phy_node = of_parse_phandle(ofdev-node
[PATCH] [V2] net: emaclite: adding MDIO and phy lib support
These changes add MDIO and phy lib support to the driver as the
IP core now supports the MDIO bus.
The MDIO bus and phy are added as a child to the emaclite in the device
tree as illustrated below.
mdio {
#address-cells = 1;
#size-cells = 0;
compatible = xlnx,emaclite-mdio;
phy0: p...@7 {
reg = 7;
} ;
}
Signed-off-by: Sadanand Mutyala sadanand.muty...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - updated it for Grant's comments, except I couldn't find any tabs
converted to white space issue, let's see if V2 has it also
---
drivers/net/Kconfig |1 +
drivers/net/xilinx_emaclite.c | 393 -
2 files changed, 351 insertions(+), 43 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index dd9a09c..9509a36 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1939,6 +1939,7 @@ config ATL2
config XILINX_EMACLITE
tristate Xilinx 10/100 Ethernet Lite support
depends on PPC32 || MICROBLAZE
+ select PHYLIB
help
This driver supports the 10/100 Ethernet Lite from Xilinx.
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 8c777ba..02f18dd 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -22,11 +22,17 @@
#include linux/of_device.h
#include linux/of_platform.h
+#include linux/of_mdio.h
+#include linux/phy.h
#define DRIVER_NAME xilinx_emaclite
/* Register offsets for the EmacLite Core */
#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
+#define XEL_MDIOADDR_OFFSET0x07E4 /* MDIO Address Register */
+#define XEL_MDIOWR_OFFSET 0x07E8 /* MDIO Write Data Register */
+#define XEL_MDIORD_OFFSET 0x07EC /* MDIO Read Data Register */
+#define XEL_MDIOCTRL_OFFSET0x07F0 /* MDIO Control Register */
#define XEL_GIER_OFFSET0x07F8 /* GIE Register */
#define XEL_TSR_OFFSET 0x07FC /* Tx status */
#define XEL_TPLR_OFFSET0x07F4 /* Tx packet length */
@@ -37,6 +43,22 @@
#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset */
+/* MDIO Address Register Bit Masks */
+#define XEL_MDIOADDR_REGADR_MASK 0x001F /* Register Address */
+#define XEL_MDIOADDR_PHYADR_MASK 0x03E0 /* PHY Address */
+#define XEL_MDIOADDR_PHYADR_SHIFT 5
+#define XEL_MDIOADDR_OP_MASK 0x0400/* RD/WR Operation */
+
+/* MDIO Write Data Register Bit Masks */
+#define XEL_MDIOWR_WRDATA_MASK 0x/* Data to be Written */
+
+/* MDIO Read Data Register Bit Masks */
+#define XEL_MDIORD_RDDATA_MASK 0x/* Data to be Read */
+
+/* MDIO Control Register Bit Masks */
+#define XEL_MDIOCTRL_MDIOSTS_MASK 0x0001 /* MDIO Status Mask */
+#define XEL_MDIOCTRL_MDIOEN_MASK 0x0008 /* MDIO Enable */
+
/* Global Interrupt Enable Register (GIER) Bit Masks */
#define XEL_GIER_GIE_MASK 0x8000 /* Global Enable */
@@ -87,6 +109,13 @@
* @reset_lock:lock used for synchronization
* @deferred_skb: holds an skb (for transmission at a later time) when the
* Tx buffer is not free
+ * @phy_dev: pointer to the PHY device
+ * @phy_node: pointer to the PHY device node
+ * @mii_bus: pointer to the MII bus
+ * @mdio_irqs: IRQs table for MDIO bus
+ * @last_link: last link status
+ * @has_mdio: indicates whether MDIO is included in the HW
+ * @mdio_mutex:protects MDIO accesses
*/
struct net_local {
@@ -100,6 +129,16 @@ struct net_local {
spinlock_t reset_lock;
struct sk_buff *deferred_skb;
+
+ struct phy_device *phy_dev;
+ struct device_node *phy_node;
+
+ struct mii_bus *mii_bus;
+ int mdio_irqs[PHY_MAX_ADDR];
+
+ int last_link;
+ bool has_mdio;
+ struct mutex mdio_mutex;
};
@@ -431,7 +470,7 @@ static u16 xemaclite_recv_data(struct net_local *drvdata,
u8 *data)
}
/**
- * xemaclite_set_mac_address - Set the MAC address for this device
+ * xemaclite_update_address - Update the MAC address in the device
* @drvdata: Pointer to the Emaclite device private data
* @address_ptr:Pointer to the MAC address (MAC address is a 48-bit value)
*
@@ -441,8 +480,8 @@ static u16 xemaclite_recv_data(struct net_local *drvdata,
u8 *data)
* The MAC address can be programmed using any of the two transmit
* buffers (if configured).
*/
-static void xemaclite_set_mac_address(struct net_local *drvdata,
- u8 *address_ptr)
+static void xemaclite_update_address(struct net_local *drvdata,
+u8 *address_ptr)
{
void __iomem *addr;
u32 reg_data;
@@ -465,6 +504,30 @@ static void xemaclite_set_mac_address(struct net_local
*drvdata
RE: Bug in drivers/serial/of_serial.c?
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Friday, November 20, 2009 2:58 PM To: Stephen Neuendorffer Cc: Arnd Bergmann; John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org Subject: Re: Bug in drivers/serial/of_serial.c? On Thu, Nov 19, 2009 at 10:42 AM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: -Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Arnd Bergmann Sent: Thursday, November 19, 2009 9:33 AM To: Stephen Neuendorffer Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org Subject: Re: Bug in drivers/serial/of_serial.c? On Thursday 19 November 2009, Stephen Neuendorffer wrote: If the problem is in the device trees that are being generated, we should fix the issue there. We've been trying to avoid putting the fully specified IP versions in the kernel like this, since the IP changes so often. No, the problem that Alon has is that the firmware currently has no way whatsoever to give a correct device tree, because of-serial.c does not even know about ns16550a. The patch adds both a special-case for the specific uart he is using so that one is grandfathered in and a new compatible value so future boards can specify both ns16550a and ns16550. That's true... The 16550a line still needs to get added, but not the xlnx- specific line. The xlnx- line should be added and is entirely appropriate for exactly the reason Arnd stated. I'm just wanting to make sure I'm on the same page... It seems like you're saying that adding this line fixes the system before any device tree generator fix, for existing systems, true? If that's true, how do you know that the 16550 in the xilinx system is not a 16450 as that's the default? Right now we're not generating the ns16450 as we should be when there are no FIFOs. Since we've been using 16550 and not 16550A it probably hasn't been a problem. -- John g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
NAK also.
Yes we can generate a different device tree to fix this issue.
Thanks,
John
-Original Message-
From: Stephen Neuendorffer
Sent: Thursday, November 19, 2009 10:23 AM
To: Alon Ziv; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
Cc: John Linn; grant.lik...@secretlab.ca
Subject: RE: Bug in drivers/serial/of_serial.c?
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
-Original Message-
From:
linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of
Alon Ziv
Sent: Thursday, November 19, 2009 5:49 AM
To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
Subject: RE: Bug in drivers/serial/of_serial.c?
On Thursday, November 19, 2009, Arnd Bergmann wrote:
I'd still add support for the compatible=ns16550a property
so that we do the right thing for future systems.
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv al...@discretix.com
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[]
= {
{ .type = serial, .compatible = ns8250, .data = (void
*)PORT_8250, },
{ .type = serial, .compatible = ns16450, .data = (void
*)PORT_16450, },
+ { .type = serial, .compatible = xlnx,xps-uart16550-2.00.b,
.data = (void *)PORT_16550A, },
{ .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550a, .data = (void
*)PORT_16550A, },
{ .type = serial, .compatible = ns16750, .data = (void
*)PORT_16750, },
{ .type = serial, .compatible = ns16850, .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
**
IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for
the
named recipient(s) only.
If you have received this email in error, please notify the system
manager or the sender
immediately
and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 0/4] xilinx_spi: Split into platform and of driver, support new IP, platform independence.
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Friday, November 13, 2009 11:30 AM To: Richard Röjfors Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net; John Linn Subject: Re: [PATCH v3 0/4] xilinx_spi: Split into platform and of driver, support new IP, platform independence. On Fri, Nov 13, 2009 at 5:28 AM, Richard Röjfors richard.rojf...@mocean-labs.com wrote: Hi, To follow is a series of patches against the xilinx_spi driver. The patchset is against 2.6.32-rc6 The patchset addresses several problems in the current driver: * It's PPC only (OF and uses PPC specific memory operations) * Only supporting big endian writes * Supports only 8bit SPI, support for DS570 (also 16 or 32 bit) is added. * A platform driver is introduced for non OF capable architectures. These patches were posted as one big patch up to 4 iterations, not splitted into 4. This version, 3, is updated after review from Grant Likely and John Linn John Linn has also tested the code on PPC, I have only tested on X86. Applied to my 'test' branch on git.secretlab.ca. There was a conflict on patch 3/4 with a previous bugfix from John Linn. Please check that I've fixed it up correctly. I think I reverted that change as Richard's fixes it I believe. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.
-Original Message-
From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
Likely
Sent: Thursday, November 12, 2009 7:56 AM
To: Richard Röjfors
Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew
Morton;
dbrown...@users.sourceforge.net; John Linn
Subject: Re: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.
On Thu, Nov 12, 2009 at 7:26 AM, Richard Röjfors
richard.rojf...@mocean-labs.com wrote:
This patch splits the xilinx_spi driver into a generic part and a
OF driver part.
The reason for this is to later add in a platform driver as well.
Signed-off-by: Richard Röjfors richard.rojf...@mocean-labs.com
---
snip
+
+ if (!ofdev-dev.platform_data) {
+ ofdev-dev.platform_data =
+ kzalloc(sizeof(struct xspi_platform_data),
GFP_KERNEL);
+ if (!ofdev-dev.platform_data)
+ return -ENOMEM;
+ }
Minor memory leak. Anything alloced in the probe path should also be
freed in the remove path. It's not going to spiral out of control or
anything, but it is important to be strict about such things. Drop
the outer if{} block here and kfree platform_data on remove.
+
+ /* number of slave select bits is required */
+ prop = of_get_property(ofdev-node, xlnx,num-ss-bits, len);
+ if (!prop || len sizeof(*prop)) {
+ dev_warn(ofdev-dev, no 'xlnx,num-ss-bits' property\n);
+ return -EINVAL;
+ }
+ ofdev-dev.platform_data-num_chipselect = *prop;
Have you compile tested this? platform_data is a void*, the
dereference will not work. I know you don't have hardware; but
getting the needed cross compiler is easy.
Here's the fixes I did to make it compile. On to testing :)
Thanks,
John
diff --git a/drivers/spi/xilinx_spi_of.c b/drivers/spi/xilinx_spi_of.c
index 13e1591..2dea9f3 100644
--- a/drivers/spi/xilinx_spi_of.c
+++ b/drivers/spi/xilinx_spi_of.c
@@ -39,6 +39,7 @@
static int __init xilinx_spi_of_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
+ struct xspi_platform_data *pdata = ofdev-dev.platform_data;
struct resource r_irq_struct;
struct resource r_mem_struct;
struct spi_master *master;
@@ -74,8 +75,8 @@ static int __init xilinx_spi_of_probe(struct of_device *ofdev,
dev_warn(ofdev-dev, no 'xlnx,num-ss-bits' property\n);
return -EINVAL;
}
- ofdev-dev.platform_data-num_chipselect = *prop;
- ofdev-dev.platform_data-bits_per_word = 8;
+ pdata-num_chipselect = *prop;
+ pdata-bits_per_word = 8;
master = xilinx_spi_init(ofdev-dev, r_mem, r_irq-start, -1);
if (!master)
return -ENODEV;
+ master = xilinx_spi_init(ofdev-dev, r_mem, r_irq-start, -1);
+ if (!master)
+ return -ENODEV;
+
+ dev_set_drvdata(ofdev-dev, master);
+
+ /* Add any subnodes on the SPI bus */
+ of_register_spi_devices(master, ofdev-node);
+
+ return 0;
+}
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4] xilinx_spi: Switch to iomem functions and support little endian.
-Original Message-
From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com]
Sent: Wednesday, November 11, 2009 7:39 AM
To: spi-devel-gene...@lists.sourceforge.net
Cc: linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net;
John Linn;
grant.lik...@secretlab.ca
Subject: [PATCH 2/4] xilinx_spi: Switch to iomem functions and support little
endian.
This patch changes the out_(be)(8|16|32) and in_(be)(8|16|32) calls to
iowrite(8|16|32)
and ioread(8|16|32). This to be able to build on platforms not supporting the
in/out calls
for instance x86.
Support is also added for little endian writes. In some systems the registers
should be
accessed little endian rather than big endian.
Signed-off-by: Richard Röjfors richard.rojf...@mocean-labs.com
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index e60b264..9667650 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -236,7 +236,7 @@ config SPI_TXX9
config SPI_XILINX
tristate Xilinx SPI controller
- depends on EXPERIMENTAL
+ depends on HAS_IOMEM EXPERIMENTAL
select SPI_BITBANG
help
This exposes the SPI controller IP from the Xilinx EDK.
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 1562e9b..b00dabc 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -19,12 +19,12 @@
#include linux/spi/spi_bitbang.h
#include linux/io.h
-#define XILINX_SPI_NAME xilinx_spi
+#include xilinx_spi.h
/* Register definitions as per OPB Serial Peripheral Interface (SPI)
(v1.00e)
* Product Specification, DS464
*/
-#define XSPI_CR_OFFSET 0x62/* 16-bit Control Register */
+#define XSPI_CR_OFFSET 0x60/* 16-bit Control Register */
#define XSPI_CR_ENABLE 0x02
#define XSPI_CR_MASTER_MODE 0x04
@@ -36,7 +36,7 @@
#define XSPI_CR_MANUAL_SSELECT 0x80
#define XSPI_CR_TRANS_INHIBIT0x100
-#define XSPI_SR_OFFSET 0x67/* 8-bit Status Register */
+#define XSPI_SR_OFFSET 0x64/* 8-bit Status Register */
#define XSPI_SR_RX_EMPTY_MASK0x01/* Receive FIFO is empty */
#define XSPI_SR_RX_FULL_MASK 0x02/* Receive FIFO is full */
@@ -44,8 +44,8 @@
#define XSPI_SR_TX_FULL_MASK 0x08/* Transmit FIFO is full */
#define XSPI_SR_MODE_FAULT_MASK 0x10/* Mode fault error */
-#define XSPI_TXD_OFFSET 0x6b/* 8-bit Data Transmit Register
*/
-#define XSPI_RXD_OFFSET 0x6f/* 8-bit Data Receive Register
*/
+#define XSPI_TXD_OFFSET 0x68/* 8-bit Data Transmit Register
*/
+#define XSPI_RXD_OFFSET 0x6c/* 8-bit Data Receive Register
*/
#define XSPI_SSR_OFFSET 0x70/* 32-bit Slave Select Register
*/
@@ -83,23 +83,69 @@ struct xilinx_spi {
u8 *rx_ptr; /* pointer in the Tx buffer */
const u8 *tx_ptr; /* pointer in the Rx buffer */
int remaining_bytes;/* the number of bytes left to transfer */
+ bool big_endian;/* The device could be accessed big or little
+ * endian
+ */
};
-static void xspi_init_hw(void __iomem *regs_base)
+/* to follow are some functions that does little of big endian read and
+ * write depending on the config of the device.
+ */
+static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 val)
+{
+ iowrite8(val, xspi-regs + offs + ((xspi-big_endian) ? 3 : 0));
+}
+
+static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u16 val)
+{
+ if (xspi-big_endian)
+ iowrite16be(val, xspi-regs + offs + 2);
+ else
+ iowrite16(val, xspi-regs + offs);
+}
+
+static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u32 val)
+{
+ if (xspi-big_endian)
+ iowrite32be(val, xspi-regs + offs);
+ else
+ iowrite32(val, xspi-regs + offs);
+}
+
+static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
+{
+ return ioread8(xspi-regs + offs + ((xspi-big_endian) ? 3 : 0));
+}
+
+static inline u16 xspi_read16(struct xilinx_spi *xspi, u32 offs)
+{
+ if (xspi-big_endian)
+ return ioread16be(xspi-regs + offs + 2);
+ else
+ return ioread16(xspi-regs + offs);
+}
+
+static inline u32 xspi_read32(struct xilinx_spi *xspi, u32 offs)
+{
+ if (xspi-big_endian)
+ return ioread32be(xspi-regs + offs);
+ else
+ return ioread32(xspi-regs + offs);
+}
+
Hi Richard,
The registers of the device should all be accessible as 32 bit operations.
It seems like it would be simpler to do that.
Thanks,
John
+static void xspi_init_hw(struct xilinx_spi *xspi)
{
/* Reset the SPI device */
- out_be32(regs_base + XIPIF_V123B_RESETR_OFFSET,
- XIPIF_V123B_RESET_MASK
RE: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
-Original Message-
From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
Likely
Sent: Tuesday, November 10, 2009 9:45 AM
To: Richard Röjfors
Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew
Morton;
dbrown...@users.sourceforge.net; John Linn
Subject: Re: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into
generic, of and platform
driver, added support for DS570
On Tue, Nov 10, 2009 at 9:19 AM, Richard Röjfors
richard.rojf...@mocean-labs.com wrote:
Grant Likely wrote:
Oops, I replied to the original version, but missed the subsequent
versions. Looks like some of my comments still apply though.
Overall, the patch changes too many things all at once. You should
look at splitting it up. At the very least the io accessor changes
should be done in a separate patch.
Hi Richard. Please do another spin of this patch. I don't have any
particular problem with the changes, but it needs to be in a more
granular form so I can review it properly.
I agree.
We have a functioning driver such that I need to make sure it doesn't regress.
More granular changes will also allow us to better isolate any problems if they
occur.
Thanks,
John
+struct xilinx_spi {
+ /* bitbang has to be first */
+ struct spi_bitbang bitbang;
+ struct completion done;
+ struct resource mem; /* phys mem */
+ void __iomem *regs; /* virt. address of the control registers
*/
+ u32 irq;
+ u8 *rx_ptr; /* pointer in the Tx buffer */
+ const u8 *tx_ptr; /* pointer in the Rx buffer */
+ int remaining_bytes; /* the number of bytes left to transfer */
+ /* offset to the XSPI regs, these might vary... */
+ u8 bits_per_word;
+ bool big_endian; /* The device could be accessed big or
little
+ * endian
+ */
+};
+
Why is the definition of xilinx_spi moved?
I liked the idea of heaving the struct defined in the top of the file.
... which is completely unrelated to the patch purpose, and is not
mentioned in the patch header. If you really want to move it then put
it in a completely separate patch and describe the change properly.
As it is right now it is just noise that makes the stated purpose of
the patch hard to review.
Ah, you changed these to functions instead of macros. I like.
However, as you suggested elsewhere in this thread, you could change
these to callbacks and then eliminate the if/else statements. I think
that is the approach you should use. I don't think you need to worry
about it being slower. Any extra cycles for jumping to a callback
will be far dwarfed by the number of cycles it takes to complete an
SPI transfer.
Sure that can be updated. I prefer to do that in an incremental patch,
would be great to get this
big one merged first.
As already commented on, this patch is too big and does too many
unrelated things. Please split into discrete changes so it can be
reviewed properly.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
-Original Message-
From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com]
Sent: Tuesday, September 29, 2009 12:35 AM
To: John Linn
Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org;
dbrown...@users.sourceforge.net; Andrew Morton
Subject: Re: [PATCH v4] xilinx_spi: Splitted into generic, of and platform
driver, added support for
DS570
On 9/28/09 5:41 PM, John Linn wrote:
-Original Message-
From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com]
Sent: Monday, September 28, 2009 8:22 AM
To: spi-devel-gene...@lists.sourceforge.net
Cc: linuxppc-...@ozlabs.org; dbrown...@users.sourceforge.net; Andrew
Morton; John Linn
Subject: [PATCH v4] xilinx_spi: Splitted into generic, of and platform
driver, added support for
DS570
This patch splits xilinx_spi into three parts, an OF and a platform
driver and generic part.
The generic part now also works on X86, it supports accessing the IP
booth big and little endian. There is also support for 16 and 32 bit
SPI for the Xilinx SPI IP DS570
Signed-off-by: Richard Röjfors richard.rojf...@mocean-labs.com
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2c733c2..ecabc12 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -218,8 +218,8 @@ config SPI_TXX9
SPI driver for Toshiba TXx9 MIPS SoCs
snip
-struct xilinx_spi {
- /* bitbang has to be first */
- struct spi_bitbang bitbang;
- struct completion done;
+/* to follow are some functions that does little of big endian read and
+ * write depending on the config of the device.
+ */
+static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 val)
+{
+ iowrite8(val, xspi-regs + offs + ((xspi-big_endian) ? 3 : 0));
+}
- void __iomem*regs; /* virt. address of the control registers */
+static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u16
val)
+{
+ if (xspi-big_endian)
+ iowrite16be(val, xspi-regs + offs + 2);
+ else
+ iowrite16(val, xspi-regs + offs);
+}
Hi Richard,
Hi John,
Thanks for the quick feedback.
No problem. I thought at 1st that the point of the new code was performance,
but it sounds like you're trying to make sure the driver will work with a
system that can be built in many different permutations.
If you're worried about efficiency (the reason for 16 and 32 bit xfers),
why wouldn't you do the
big-endian vs little endian I/O decision at compile time rather than run time?
I'm afraid we can't do it compile time, if we want to be flexible. As
example;
The IP is big endian, in our case the PCI interface flips the byte
order. But the PCI interface might be setup differently -would be
accessed big endian even on a little endian machine.
Ok I see the flexibility requirements.
We could use callbacks set up during probe, instead of having the
if-sentence. But I don't think the callback solution could be slower (if
talking performance), since the compiler can't inline them, the current
functions could be inlined if the compiler feels like it.
The big_endian variable is not a constant boolean, I don't know if that
could help so that the
compiler optimizes this check away? Or maybe it is already and I'm just
missing that?
- u32 irq;
+static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u32
val)
+{
+ if (xspi-big_endian)
+ iowrite32be(val, xspi-regs + offs);
+ else
+ iowrite32(val, xspi-regs + offs);
+}
- u32 speed_hz; /* SCK has a fixed frequency of speed_hz Hz */
+static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
+{
+ return ioread8(xspi-regs + offs + ((xspi-big_endian) ? 3 : 0));
+}
- u8 *rx_ptr; /* pointer in the Tx buffer */
- const u8 *tx_ptr; /* pointer in the Rx buffer */
- int remaining_bytes;/* the number of bytes left to transfer */
-};
snip
-
/* This driver supports single master mode only. Hence Tx FIFO Empty
* is the only interrupt we care about.
* Receive FIFO Overrun, Transmit FIFO Underrun, Mode Fault, and Slave
Mode
@@ -237,32 +298,50 @@ static irqreturn_t xilinx_spi_irq(int irq, void
*dev_id)
u32 ipif_isr;
/* Get the IPIF interrupts, and clear them immediately */
- ipif_isr = in_be32(xspi-regs + XIPIF_V123B_IISR_OFFSET);
- out_be32(xspi-regs + XIPIF_V123B_IISR_OFFSET, ipif_isr);
+ ipif_isr = xspi_read32(xspi, XIPIF_V123B_IISR_OFFSET);
+ xspi_write32(xspi, XIPIF_V123B_IISR_OFFSET, ipif_isr);
if (ipif_isr XSPI_INTR_TX_EMPTY) {/* Transmission completed */
u16 cr;
u8 sr;
+ u8 rsize;
+ if (xspi-bits_per_word == 8)
+ rsize = 1;
+ else if (xspi-bits_per_word == 16)
+ rsize = 2;
+ else
+ rsize = 4
RE: [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
-Original Message-
From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com]
Sent: Monday, September 28, 2009 8:22 AM
To: spi-devel-gene...@lists.sourceforge.net
Cc: linuxppc-...@ozlabs.org; dbrown...@users.sourceforge.net; Andrew Morton;
John Linn
Subject: [PATCH v4] xilinx_spi: Splitted into generic, of and platform
driver, added support for
DS570
This patch splits xilinx_spi into three parts, an OF and a platform
driver and generic part.
The generic part now also works on X86, it supports accessing the IP
booth big and little endian. There is also support for 16 and 32 bit
SPI for the Xilinx SPI IP DS570
Signed-off-by: Richard Röjfors richard.rojf...@mocean-labs.com
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2c733c2..ecabc12 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -218,8 +218,8 @@ config SPI_TXX9
SPI driver for Toshiba TXx9 MIPS SoCs
snip
-struct xilinx_spi {
- /* bitbang has to be first */
- struct spi_bitbang bitbang;
- struct completion done;
+/* to follow are some functions that does little of big endian read and
+ * write depending on the config of the device.
+ */
+static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 val)
+{
+ iowrite8(val, xspi-regs + offs + ((xspi-big_endian) ? 3 : 0));
+}
- void __iomem*regs; /* virt. address of the control registers */
+static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u16 val)
+{
+ if (xspi-big_endian)
+ iowrite16be(val, xspi-regs + offs + 2);
+ else
+ iowrite16(val, xspi-regs + offs);
+}
Hi Richard,
If you're worried about efficiency (the reason for 16 and 32 bit xfers), why
wouldn't you do the big-endian vs little endian I/O decision at compile time
rather than run time?
The big_endian variable is not a constant boolean, I don't know if that could
help so that the compiler optimizes this check away? Or maybe it is already
and I'm just missing that?
- u32 irq;
+static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u32 val)
+{
+ if (xspi-big_endian)
+ iowrite32be(val, xspi-regs + offs);
+ else
+ iowrite32(val, xspi-regs + offs);
+}
- u32 speed_hz; /* SCK has a fixed frequency of speed_hz Hz */
+static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
+{
+ return ioread8(xspi-regs + offs + ((xspi-big_endian) ? 3 : 0));
+}
- u8 *rx_ptr; /* pointer in the Tx buffer */
- const u8 *tx_ptr; /* pointer in the Rx buffer */
- int remaining_bytes;/* the number of bytes left to transfer */
-};
snip
-
/* This driver supports single master mode only. Hence Tx FIFO Empty
* is the only interrupt we care about.
* Receive FIFO Overrun, Transmit FIFO Underrun, Mode Fault, and Slave Mode
@@ -237,32 +298,50 @@ static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
u32 ipif_isr;
/* Get the IPIF interrupts, and clear them immediately */
- ipif_isr = in_be32(xspi-regs + XIPIF_V123B_IISR_OFFSET);
- out_be32(xspi-regs + XIPIF_V123B_IISR_OFFSET, ipif_isr);
+ ipif_isr = xspi_read32(xspi, XIPIF_V123B_IISR_OFFSET);
+ xspi_write32(xspi, XIPIF_V123B_IISR_OFFSET, ipif_isr);
if (ipif_isr XSPI_INTR_TX_EMPTY) {/* Transmission completed */
u16 cr;
u8 sr;
+ u8 rsize;
+ if (xspi-bits_per_word == 8)
+ rsize = 1;
+ else if (xspi-bits_per_word == 16)
+ rsize = 2;
+ else
+ rsize = 4;
/* A transmit has just completed. Process received data and
* check for more data to transmit. Always inhibit the
* transmitter while the Isr refills the transmit register/FIFO,
* or make sure it is stopped if we're done.
*/
- cr = in_be16(xspi-regs + XSPI_CR_OFFSET);
- out_be16(xspi-regs + XSPI_CR_OFFSET,
- cr | XSPI_CR_TRANS_INHIBIT);
+ cr = xspi_read16(xspi, XSPI_CR_OFFSET);
+ xspi_write16(xspi, XSPI_CR_OFFSET, cr | XSPI_CR_TRANS_INHIBIT);
/* Read out all the data from the Rx FIFO */
- sr = in_8(xspi-regs + XSPI_SR_OFFSET);
+ sr = xspi_read8(xspi, XSPI_SR_OFFSET);
while ((sr XSPI_SR_RX_EMPTY_MASK) == 0) {
- u8 data;
+ u32 data;
+ if (rsize == 1)
+ data = xspi_read8(xspi, XSPI_RXD_OFFSET);
+ else if (rsize == 2)
+ data = xspi_read16(xspi, XSPI_RXD_OFFSET);
+ else
+ data = xspi_read32(xspi, XSPI_RXD_OFFSET);
- data = in_8(xspi-regs
RE: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
-Original Message- From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com] Sent: Thursday, September 24, 2009 1:36 AM To: John Linn Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570 Hi again, John Linn wrote: -Original Message- From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com] Sent: Tuesday, September 22, 2009 3:59 PM To: John Linn Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570 John Linn wrote: -Original Message- From: linuxppc-dev-bounces+john.linn=xilinx@lists.ozlabs.org [mailto:linuxppc-dev- bounces+john.linn=xilinx@lists.ozlabs.org] On Behalf Of Richard Röjfors Sent: Tuesday, September 22, 2009 6:55 AM To: spi-devel-gene...@lists.sourceforge.net Cc: linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net Subject: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570 This patch splits xilinx_spi into three parts, an OF and a platform driver and generic part. The generic part now also works on X86 and also supports the Xilinx SPI IP DS570 Hi Richard, Hi John, The current driver (without this change) works for the newer XPS SPI device already as I run tests on it each day using an SPI EEPROM. I'm not an expert of the Xilinx SPI blocks, I have only used one, the DS570. I don't think you use the DS570. I don't have the datasheet of the older one, but the register offsets of the DS570 don't match the driver you are using. All the registers of the DS570 are at 4 bytes boundries. I just verified that I am using the same IP block as you are, the DS570. But I'm not testing on the other IP you mention, the DS464. Hi, I have now verified the differences. Actually the blocks are register offset compatible. Since the DS464 is 8 bit only, the driver is made to do only 8 bit accesses to some registers, for instance TXD. On the 570 we have to do 32 bit (or at least 16) as the driver now support more than 8bit SPI. We test against some SPI devices that are 16 bit. The offsets in the code differs from the datasheet because since the device is big endian - an 8 bit access to must happen 3 bytes up from the register base. For instance the TXD register is defined at 0x6b, while the spec says 0x68. 0x68 + 0x3 = 0x6b. To support more than 8 bit, we must do 16 bit access at 0x6a or 32 bit at 0x68. To summarize; You are completely right you can use the old driver on the DS570 as well, but _only_ for 8bit SPI. My patch allows to run on X86 and with 16 or 32bit SPI. Hi Richard, When I look at the IP block I see that the transfers can be 16 or 32 bits and allowing that would probably be more efficient for transfers. That seems like the primary benefit to me. I don't personally see a benefit of running on X86 but that's not my domain for sure. I don't know of many users using Xilinx IP with an X86, but maybe they're out there. A simpler driver is definitely better IMHO. Thanks for investigating further, John Thanks to the observation from you, I got aware of the differences. I can simplify the code by automatically increase registers offsets when doing 8 or 16 bits accesses. I will come back with an updated patch. Hope I made the situation clearer. --Richard This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
-Original Message-
From: Richard Röjfors [mailto:richard.rojf...@mocean-labs.com]
Sent: Tuesday, September 22, 2009 3:59 PM
To: John Linn
Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew
Morton;
dbrown...@users.sourceforge.net
Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform
driver, added support for
DS570
John Linn wrote:
-Original Message-
From: linuxppc-dev-bounces+john.linn=xilinx@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+john.linn=xilinx@lists.ozlabs.org] On Behalf Of Richard Röjfors
Sent: Tuesday, September 22, 2009 6:55 AM
To: spi-devel-gene...@lists.sourceforge.net
Cc: linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net
Subject: [PATCH v3] xilinx_spi: Splitted into generic, of and platform
driver, added support for
DS570
This patch splits xilinx_spi into three parts, an OF and a platform
driver and generic part.
The generic part now also works on X86 and also supports the Xilinx
SPI IP DS570
Hi Richard,
Hi John,
The current driver (without this change) works for the newer XPS SPI device
already as I run tests
on it each day using an SPI EEPROM.
I'm not an expert of the Xilinx SPI blocks, I have only used one, the DS570.
I don't think you use the DS570. I don't have the datasheet of the older one,
but the register
offsets of the DS570 don't match the driver you are using. All the registers
of the DS570 are at 4
bytes boundries.
I just verified that I am using the same IP block as you are, the DS570. But
I'm not testing on the other IP you mention, the DS464.
For instance the Status register of the code (DS464 is at offset 0x67), while
the Xilinx DS570 XPS
Serial Peripheral Interface (SPI) (v2.00b), Data Sheet, clearly specifies
that the Status register
offset of the DS570 is 0x64, which also matches the FPGA IP we run.
Do you think that's not the case, or it doesn't work for some other type of
devices that I'm not
testing with?
Did you test with some SPI device that didn't work as I'm using it with an SPI
EEPROM?
I think you use some other IP block. Could that be the case?
I'll hold off commenting on the rest of the code changes for a bit.
Thanks,
John
Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2c733c2..eca491b 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -218,8 +218,8 @@ config SPI_TXX9
SPI driver for Toshiba TXx9 MIPS SoCs
config SPI_XILINX
- tristate Xilinx SPI controller
- depends on (XILINX_VIRTEX || MICROBLAZE) EXPERIMENTAL
+ tristate Xilinx SPI controller common module
+ depends on (XILINX_VIRTEX || MICROBLAZE || HAS_IOMEM) EXPERIMENTAL
select SPI_BITBANG
help
This exposes the SPI controller IP from the Xilinx EDK.
@@ -227,6 +227,22 @@ config SPI_XILINX
See the OPB Serial Peripheral Interface (SPI) (v1.00e)
Product Specification document (DS464) for hardware details.
+Or for the DS570, see XPS Serial Peripheral Interface (SPI) (v2.00b)
+
+
+config SPI_XILINX_OF
+ tristate Xilinx SPI controller OF device
+ depends on SPI_XILINX XILINX_VIRTEX
+ help
+This is the OF driver for the SPI controller IP from the Xilinx EDK.
+
+config SPI_XILINX_PLTFM
+ tristate Xilinx SPI controller platform device
+ depends on SPI_XILINX
+ help
+This is the platform driver for the SPI controller IP
+from the Xilinx EDK.
+
#
# Add new SPI master controllers in alphabetical order above this line
#
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 3de408d..5a91cf5 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_SPI_S3C24XX_GPIO) +=
spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9)+= spi_txx9.o
obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
+obj-$(CONFIG_SPI_XILINX_OF) += xilinx_spi_of.o
+obj-$(CONFIG_SPI_XILINX_PLTFM)+= xilinx_spi_pltfm.o
obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o
# ... add above this line ...
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..0490820 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -14,22 +14,103 @@
#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
-#include linux/platform_device.h
-
-#include linux/of_platform.h
-#include linux/of_device.h
-#include linux/of_spi.h
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
#include linux/io.h
-#define XILINX_SPI_NAME xilinx_spi
+#include xilinx_spi.h
+
+struct xilinx_spi {
+ /* bitbang has to be first */
+ struct spi_bitbang bitbang
[PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
From: Michal Simek mon...@monstr.eu
You can't ping the board or connect to it unless you send
any packet out from board.
Tested-by: John Williams john.willi...@petalogix.com
Signed-off-by: Michal Simek mon...@monstr.eu
Acked-by: John Linn john.l...@xilinx.com
---
drivers/net/xilinx_emaclite.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index dc22782..83a044d 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -134,18 +134,15 @@ static void xemaclite_enable_interrupts(struct net_local
*drvdata)
}
/* Enable the Rx interrupts for the first buffer */
- reg_data = in_be32(drvdata-base_addr + XEL_RSR_OFFSET);
out_be32(drvdata-base_addr + XEL_RSR_OFFSET,
-reg_data | XEL_RSR_RECV_IE_MASK);
+XEL_RSR_RECV_IE_MASK);
/* Enable the Rx interrupts for the second Buffer if
* configured in HW */
if (drvdata-rx_ping_pong != 0) {
- reg_data = in_be32(drvdata-base_addr + XEL_BUFFER_OFFSET +
- XEL_RSR_OFFSET);
out_be32(drvdata-base_addr + XEL_BUFFER_OFFSET +
XEL_RSR_OFFSET,
-reg_data | XEL_RSR_RECV_IE_MASK);
+XEL_RSR_RECV_IE_MASK);
}
/* Enable the Global Interrupt Enable */
--
1.6.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
-Original Message-
From: linuxppc-dev-bounces+john.linn=xilinx@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+john.linn=xilinx@lists.ozlabs.org] On Behalf Of Richard Röjfors
Sent: Tuesday, September 22, 2009 6:55 AM
To: spi-devel-gene...@lists.sourceforge.net
Cc: linuxppc-...@ozlabs.org; Andrew Morton; dbrown...@users.sourceforge.net
Subject: [PATCH v3] xilinx_spi: Splitted into generic, of and platform
driver, added support for
DS570
This patch splits xilinx_spi into three parts, an OF and a platform
driver and generic part.
The generic part now also works on X86 and also supports the Xilinx
SPI IP DS570
Hi Richard,
The current driver (without this change) works for the newer XPS SPI device
already as I run tests on it each day using an SPI EEPROM.
Do you think that's not the case, or it doesn't work for some other type of
devices that I'm not testing with?
I'll hold off commenting on the rest of the code changes for a bit.
Thanks,
John
Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2c733c2..eca491b 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -218,8 +218,8 @@ config SPI_TXX9
SPI driver for Toshiba TXx9 MIPS SoCs
config SPI_XILINX
- tristate Xilinx SPI controller
- depends on (XILINX_VIRTEX || MICROBLAZE) EXPERIMENTAL
+ tristate Xilinx SPI controller common module
+ depends on (XILINX_VIRTEX || MICROBLAZE || HAS_IOMEM) EXPERIMENTAL
select SPI_BITBANG
help
This exposes the SPI controller IP from the Xilinx EDK.
@@ -227,6 +227,22 @@ config SPI_XILINX
See the OPB Serial Peripheral Interface (SPI) (v1.00e)
Product Specification document (DS464) for hardware details.
+ Or for the DS570, see XPS Serial Peripheral Interface (SPI) (v2.00b)
+
+
+config SPI_XILINX_OF
+ tristate Xilinx SPI controller OF device
+ depends on SPI_XILINX XILINX_VIRTEX
+ help
+ This is the OF driver for the SPI controller IP from the Xilinx EDK.
+
+config SPI_XILINX_PLTFM
+ tristate Xilinx SPI controller platform device
+ depends on SPI_XILINX
+ help
+ This is the platform driver for the SPI controller IP
+ from the Xilinx EDK.
+
#
# Add new SPI master controllers in alphabetical order above this line
#
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 3de408d..5a91cf5 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_SPI_S3C24XX_GPIO) +=
spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX)+= spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
+obj-$(CONFIG_SPI_XILINX_OF) += xilinx_spi_of.o
+obj-$(CONFIG_SPI_XILINX_PLTFM) += xilinx_spi_pltfm.o
obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o
#... add above this line ...
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..0490820 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -14,22 +14,103 @@
#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
-#include linux/platform_device.h
-
-#include linux/of_platform.h
-#include linux/of_device.h
-#include linux/of_spi.h
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
#include linux/io.h
-#define XILINX_SPI_NAME xilinx_spi
+#include xilinx_spi.h
+
+struct xilinx_spi {
+ /* bitbang has to be first */
+ struct spi_bitbang bitbang;
+ struct completion done;
+ struct resource mem; /* phys mem */
+ void __iomem*regs; /* virt. address of the control registers */
+ u32 irq;
+ u8 *rx_ptr; /* pointer in the Tx buffer */
+ const u8 *tx_ptr; /* pointer in the Rx buffer */
+ int remaining_bytes;/* the number of bytes left to transfer */
+ /* offset to the XSPI regs, these might vary... */
+ u8 cr_offset;
+ u8 sr_offset;
+ u8 txd_offset;
+ u8 rxd_offset;
+ u8 ssr_offset;
+ u8 bits_per_word;
+ u8 model;
+};
+
+#ifdef CONFIG_X86
+/* on X86 the block often resides behind a PCI(e) interface which flips the
+ * endian from little to big
+ */
+#define xspi_in8(addr) ioread8(addr)
+#define xspi_in16(addr) ioread16(addr)
+#define xspi_in32(addr) ioread32(addr)
+
+#define xspi_out8(addr, b) iowrite8(b, addr)
+#define xspi_out16(addr, w) iowrite16(w, addr)
+#define xspi_out32(addr, l) iowrite32(l, addr)
+#else
+/* While on for instance PPC we use big endian */
+#define xspi_in8(addr) in_8(addr)
+#define xspi_in16(addr) in_be16(addr)
+#define xspi_in32(addr) in_be32(addr)
+
+#define xspi_out8(addr, b) out_8(addr, b)
+#define xspi_out16(addr, w) out_be16(addr, w)
+#define xspi_out32(addr, l) out_be32(addr, l)
+#endif
+
+
+static
RE: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
Thanks Grant, I wondered about that myself.
-Original Message-
From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
Likely
Sent: Tuesday, September 22, 2009 10:54 AM
To: John Linn
Cc: net...@vger.kernel.org; da...@davemloft.net; linuxppc-...@ozlabs.org;
jwbo...@linux.vnet.ibm.com;
Sadanand Mutyala; Michal Simek
Subject: Re: [PATCH] net: xilinx_emaclite: Fix problem with first incoming
packet
On Tue, Sep 22, 2009 at 8:24 AM, John Linn john.l...@xilinx.com wrote:
From: Michal Simek mon...@monstr.eu
You can't ping the board or connect to it unless you send
any packet out from board.
Tested-by: John Williams john.willi...@petalogix.com
Signed-off-by: Michal Simek mon...@monstr.eu
Acked-by: John Linn john.l...@xilinx.com
John, Since this patch is being *sent* by you, then you should use a
signed-off-by tag instead because it actually passed through your
hands.
Oh, and:
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/xilinx_emaclite.c | 7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index dc22782..83a044d 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -134,18 +134,15 @@ static void xemaclite_enable_interrupts(struct
net_local *drvdata)
}
/* Enable the Rx interrupts for the first buffer */
- reg_data = in_be32(drvdata-base_addr + XEL_RSR_OFFSET);
out_be32(drvdata-base_addr + XEL_RSR_OFFSET,
- reg_data | XEL_RSR_RECV_IE_MASK);
+ XEL_RSR_RECV_IE_MASK);
/* Enable the Rx interrupts for the second Buffer if
* configured in HW */
if (drvdata-rx_ping_pong != 0) {
- reg_data = in_be32(drvdata-base_addr + XEL_BUFFER_OFFSET +
- XEL_RSR_OFFSET);
out_be32(drvdata-base_addr + XEL_BUFFER_OFFSET +
XEL_RSR_OFFSET,
- reg_data | XEL_RSR_RECV_IE_MASK);
+ XEL_RSR_RECV_IE_MASK);
}
/* Enable the Global Interrupt Enable */
--
1.6.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and
contain(s) confidential information that may be proprietary, privileged or
copyrighted under
applicable law. If you are not the intended recipient, do not read, copy, or
forward this email
message or any attachments. Delete this email message and any attachments
immediately.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Xilinx: SPI: Fix bits_per_word for transfers
The bits_per_word value can be set for each transfer, or can
be set to zero in each transfer in which case it should default
to the value in the driver.
The driver was fixed to properly check the bits_per_word in
the transfer that is passed in.
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/spi/xilinx_spi.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..5a143b9 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -148,7 +148,8 @@ static int xilinx_spi_setup_transfer(struct spi_device *spi,
{
u8 bits_per_word;
- bits_per_word = (t) ? t-bits_per_word : spi-bits_per_word;
+ bits_per_word = (t t-bits_per_word)
+? t-bits_per_word : spi-bits_per_word;
if (bits_per_word != 8) {
dev_err(spi-dev, %s, unsupported bits_per_word=%d\n,
__func__, bits_per_word);
--
1.6.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V3] net: add Xilinx emac lite device driver
-Original Message-
From: Stephen Hemminger [mailto:shemmin...@vyatta.com]
Sent: Thursday, August 20, 2009 5:49 PM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
da...@davemloft.net; jgar...@pobox.com; John
Linn; grant.lik...@secretlab.ca; Josh Boyer; John Williams; Michal
Simek; Sadanand Mutyala
Subject: Re: [PATCH] [V3] net: add Xilinx emac lite device driver
On Thu, 20 Aug 2009 03:49:51 -0600
John Linn john.l...@xilinx.com wrote:
+/**
+ * xemaclite_ioctl - Perform IO Control operations on the network
device
+ * @dev: Pointer to the network device
+ * @rq:Pointer to the interface request structure
+ * @cmd: IOCTL command
+ *
+ * The only IOCTL operation supported by this function is setting
the MAC
+ * address. An error is reported if any other operations are
requested.
+ *
+ * Return: 0 to indicate success, or a negative error for failure.
+ */
+static int xemaclite_ioctl(struct net_device *dev, struct ifreq
*rq, int cmd)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ struct hw_addr_data *hw_addr = (struct hw_addr_data *)
rq-ifr_hwaddr;
+
+ switch (cmd) {
+ case SIOCETHTOOL:
+ return -EIO;
+
+ case SIOCSIFHWADDR:
+ dev_err(lp-ndev-dev, SIOCSIFHWADDR\n);
+
+ /* Copy MAC address in from user space */
+ copy_from_user((void __force *) dev-dev_addr,
+ (void __user __force *) hw_addr,
+ IFHWADDRLEN);
+ xemaclite_set_mac_address(lp, dev-dev_addr);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
Do you really need this? I doubt the SIOCSIFHWADDR even reaches
driver!
The normal call path for setting hardware address is:
dev_ifsioc
dev_set_mac_address
ops-ndo_set_mac_address --
The driver should be:
1. defining new code to do ndo_set_mac_address
2. remove existing xmaclite_ioctl - all ioctl's handled by upper
layers
FYI - the only ioctl's that make it to network device ndo_ioctl
are listed in dev_ifsioc
SIOCDEVPRIVATE ... SIOCDEVPRIVATE + 15
SIOCBOND*
SIOCMII*
SIOCBR*
SIOCHWTSTAMP
SIOCWANDEV
We agree and will be updating the driver for this change. Sorry about
the delay as I was on vacation.
Thanks,
John
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V2] net: add Xilinx emac lite device driver
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, August 20, 2009 10:31 AM To: michal.si...@petalogix.com Cc: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; Sadanand Mutyala Subject: Re: [PATCH] [V2] net: add Xilinx emac lite device driver From: Michal Simek michal.si...@petalogix.com Date: Thu, 20 Aug 2009 11:28:48 +0200 There were one bug with spinlock which John L fixed but not send to mainling list. :-( He wanted to create new v3 version. :-(. When he wake up, he send you that bug fix or v3 version with it. Send a new version, I'll revert V2 from my tree as I didn't push it out yet. I'll send a V3 version very soon, thanks. Sorry for the hassle as I thought there would be more comments and I'd incorporate the bug fix into those. Appreciate your help. -- John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [V3] net: add Xilinx emac lite device driver
This patch adds support for the Xilinx Ethernet Lite device. The soft logic core from Xilinx is typically used on Virtex and Spartan designs attached to either a PowerPC or a Microblaze processor. CC: Grant Likely grant.lik...@secretlab.ca CC: Josh Boyer jwbo...@linux.vnet.ibm.com CC: John Williams john.willi...@petalogix.com CC: Michal Simek michal.si...@petalogix.com Signed-off-by: Sadanand M sada...@xilinx.com Signed-off-by: John Linn john.l...@xilinx.com --- V2 - cleanup based on review, added depends for ppc and mb in Kconfig V3 - fixed bug, spin lock was not initialized --- drivers/net/Kconfig |6 + drivers/net/Makefile |1 + drivers/net/xilinx_emaclite.c | 1041 + 3 files changed, 1048 insertions(+), 0 deletions(-) create mode 100755 drivers/net/xilinx_emaclite.c diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 5f6509a..ec77b69 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1926,6 +1926,12 @@ config ATL2 To compile this driver as a module, choose M here. The module will be called atl2. +config XILINX_EMACLITE + tristate Xilinx 10/100 Ethernet Lite support + depends on PPC32 || MICROBLAZE + help + This driver supports the 10/100 Ethernet Lite from Xilinx. + source drivers/net/fs_enet/Kconfig endif # NET_ETHERNET diff --git a/drivers/net/Makefile b/drivers/net/Makefile index ead8cab..99ae6d7 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -142,6 +142,7 @@ obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o ll_temac-objs := ll_temac_main.o ll_temac_mdio.o obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o +obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o obj-$(CONFIG_QLA3XXX) += qla3xxx.o obj-$(CONFIG_QLGE) += qlge/ diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c new file mode 100755 index 000..7e05b40 --- /dev/null +++ b/drivers/net/xilinx_emaclite.c @@ -0,0 +1,1041 @@ +/* + * Xilinx EmacLite Linux driver for the Xilinx Ethernet MAC Lite device. + * + * This is a new flat driver which is based on the original emac_lite + * driver from John Williams john.willi...@petalogix.com. + * + * 2007-2009 (c) Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/module.h +#include linux/uaccess.h +#include linux/init.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/io.h + +#include linux/of_device.h +#include linux/of_platform.h + +#define DRIVER_NAME xilinx_emaclite + +/* Register offsets for the EmacLite Core */ +#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */ +#define XEL_GIER_OFFSET0x07F8 /* GIE Register */ +#define XEL_TSR_OFFSET 0x07FC /* Tx status */ +#define XEL_TPLR_OFFSET0x07F4 /* Tx packet length */ + +#define XEL_RXBUFF_OFFSET 0x1000 /* Receive Buffer */ +#define XEL_RPLR_OFFSET0x100C /* Rx packet length */ +#define XEL_RSR_OFFSET 0x17FC /* Rx status */ + +#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset */ + +/* Global Interrupt Enable Register (GIER) Bit Masks */ +#define XEL_GIER_GIE_MASK 0x8000 /* Global Enable */ + +/* Transmit Status Register (TSR) Bit Masks */ +#define XEL_TSR_XMIT_BUSY_MASK 0x0001 /* Tx complete */ +#define XEL_TSR_PROGRAM_MASK0x0002 /* Program the MAC address */ +#define XEL_TSR_XMIT_IE_MASK0x0008 /* Tx interrupt enable bit */ +#define XEL_TSR_XMIT_ACTIVE_MASK 0x8000/* Buffer is active, SW bit +* only. This is not documented +* in the HW spec */ + +/* Define for programming the MAC address into the EmacLite */ +#define XEL_TSR_PROG_MAC_ADDR (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK) + +/* Receive Status Register (RSR) */ +#define XEL_RSR_RECV_DONE_MASK 0x0001 /* Rx complete */ +#define XEL_RSR_RECV_IE_MASK 0x0008 /* Rx interrupt enable bit */ + +/* Transmit Packet Length Register (TPLR) */ +#define XEL_TPLR_LENGTH_MASK 0x /* Tx packet length */ + +/* Receive Packet Length Register (RPLR) */ +#define XEL_RPLR_LENGTH_MASK 0x /* Rx packet length */ + +#define XEL_HEADER_OFFSET 12 /* Offset to length field */ +#define XEL_HEADER_SHIFT 16 /* Shift value for length */ + +/* General Ethernet Definitions */ +#define XEL_ARP_PACKET_SIZE28 /* Max ARP packet size */ +#define XEL_HEADER_IP_LENGTH_OFFSET16 /* IP Length Offset
RE: [PATCH] net: add Xilinx emac lite device driver
Thanks David, I may have got over zealous in my clean up to get it ready for mainline. I'll take care of that. -- John -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Wednesday, August 19, 2009 7:28 AM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; michal.si...@petalogix.com; Sadanand Mutyala Subject: Re: [PATCH] net: add Xilinx emac lite device driver From: John Linn john.l...@xilinx.com Date: Tue, 18 Aug 2009 09:30:41 -0600 @@ -1926,6 +1926,11 @@ config ATL2 To compile this driver as a module, choose M here. The module will be called atl2. +config XILINX_EMACLITE + tristate Xilinx 10/100 Ethernet Lite support + help + This driver supports the 10/100 Ethernet Lite from Xilinx. + source drivers/net/fs_enet/Kconfig endif # NET_ETHERNET You can't unconditionally enable this driver everywhere. It depends upon things like openfirmware support, etc. so the driver will fail to link if the architecture doesn't have those support routines. Please fix this up, thanks. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] net: add Xilinx emac lite device driver
-Original Message- From: Stephen Hemminger [mailto:shemmin...@vyatta.com] Sent: Tuesday, August 18, 2009 10:04 PM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com; da...@davemloft.net; John Linn; grant.lik...@secretlab.ca; Josh Boyer; John Williams; Michal Simek; Sadanand Mutyala Subject: Re: [PATCH] net: add Xilinx emac lite device driver On Tue, 18 Aug 2009 09:30:41 -0600 John Linn john.l...@xilinx.com wrote: +/** + * xemaclite_enable_interrupts - Enable the interrupts for the EmacLite device + * @drvdata: Pointer to the Emaclite device private data + * + * This function enables the Tx and Rx interrupts for the Emaclite device along + * with the Global Interrupt Enable. + */ +static void xemaclite_enable_interrupts(struct net_local *drvdata) Docbook format is really a not necessary on local functions that are only used in the driver. It is fine if you want to use it, as long as the file isn't processed by kernel make docs but the docbook is intended for automatic generation of kernel API manuals. Thanks, we realize that and have been consistent with our drivers in that area. We aren't adding them to the make for the docs so it doesn't seem like it should be a problem. -- This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [V2] net: add Xilinx emac lite device driver
This patch adds support for the Xilinx Ethernet Lite device. The soft logic core from Xilinx is typically used on Virtex and Spartan designs attached to either a PowerPC or a Microblaze processor. CC: Grant Likely grant.lik...@secretlab.ca CC: Josh Boyer jwbo...@linux.vnet.ibm.com CC: John Williams john.willi...@petalogix.com CC: Michal Simek michal.si...@petalogix.com Signed-off-by: Sadanand M sada...@xilinx.com Signed-off-by: John Linn john.l...@xilinx.com --- V2 - cleanup based on review, added depends for ppc and mb in Kconfig --- drivers/net/Kconfig |6 + drivers/net/Makefile |1 + drivers/net/xilinx_emaclite.c | 1040 + 3 files changed, 1047 insertions(+), 0 deletions(-) create mode 100755 drivers/net/xilinx_emaclite.c diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 5f6509a..ec77b69 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1926,6 +1926,12 @@ config ATL2 To compile this driver as a module, choose M here. The module will be called atl2. +config XILINX_EMACLITE + tristate Xilinx 10/100 Ethernet Lite support + depends on PPC32 || MICROBLAZE + help + This driver supports the 10/100 Ethernet Lite from Xilinx. + source drivers/net/fs_enet/Kconfig endif # NET_ETHERNET diff --git a/drivers/net/Makefile b/drivers/net/Makefile index ead8cab..99ae6d7 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -142,6 +142,7 @@ obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o ll_temac-objs := ll_temac_main.o ll_temac_mdio.o obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o +obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o obj-$(CONFIG_QLA3XXX) += qla3xxx.o obj-$(CONFIG_QLGE) += qlge/ diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c new file mode 100755 index 000..3716e20 --- /dev/null +++ b/drivers/net/xilinx_emaclite.c @@ -0,0 +1,1040 @@ +/* + * Xilinx EmacLite Linux driver for the Xilinx Ethernet MAC Lite device. + * + * This is a new flat driver which is based on the original emac_lite + * driver from John Williams john.willi...@petalogix.com. + * + * 2007-2009 (c) Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/module.h +#include linux/uaccess.h +#include linux/init.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/io.h + +#include linux/of_device.h +#include linux/of_platform.h + +#define DRIVER_NAME xilinx_emaclite + +/* Register offsets for the EmacLite Core */ +#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */ +#define XEL_GIER_OFFSET0x07F8 /* GIE Register */ +#define XEL_TSR_OFFSET 0x07FC /* Tx status */ +#define XEL_TPLR_OFFSET0x07F4 /* Tx packet length */ + +#define XEL_RXBUFF_OFFSET 0x1000 /* Receive Buffer */ +#define XEL_RPLR_OFFSET0x100C /* Rx packet length */ +#define XEL_RSR_OFFSET 0x17FC /* Rx status */ + +#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset */ + +/* Global Interrupt Enable Register (GIER) Bit Masks */ +#define XEL_GIER_GIE_MASK 0x8000 /* Global Enable */ + +/* Transmit Status Register (TSR) Bit Masks */ +#define XEL_TSR_XMIT_BUSY_MASK 0x0001 /* Tx complete */ +#define XEL_TSR_PROGRAM_MASK0x0002 /* Program the MAC address */ +#define XEL_TSR_XMIT_IE_MASK0x0008 /* Tx interrupt enable bit */ +#define XEL_TSR_XMIT_ACTIVE_MASK 0x8000/* Buffer is active, SW bit +* only. This is not documented +* in the HW spec */ + +/* Define for programming the MAC address into the EmacLite */ +#define XEL_TSR_PROG_MAC_ADDR (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK) + +/* Receive Status Register (RSR) */ +#define XEL_RSR_RECV_DONE_MASK 0x0001 /* Rx complete */ +#define XEL_RSR_RECV_IE_MASK 0x0008 /* Rx interrupt enable bit */ + +/* Transmit Packet Length Register (TPLR) */ +#define XEL_TPLR_LENGTH_MASK 0x /* Tx packet length */ + +/* Receive Packet Length Register (RPLR) */ +#define XEL_RPLR_LENGTH_MASK 0x /* Rx packet length */ + +#define XEL_HEADER_OFFSET 12 /* Offset to length field */ +#define XEL_HEADER_SHIFT 16 /* Shift value for length */ + +/* General Ethernet Definitions */ +#define XEL_ARP_PACKET_SIZE28 /* Max ARP packet size */ +#define XEL_HEADER_IP_LENGTH_OFFSET16 /* IP Length Offset */ + + + +#define TX_TIMEOUT (60*HZ
[PATCH] net: add Xilinx emac lite device driver
This patch adds support for the Xilinx Ethernet Lite device. The soft logic core from Xilinx is typically used on Virtex and Spartan designs attached to either a PowerPC or a Microblaze processor. CC: Grant Likely grant.lik...@secretlab.ca CC: Josh Boyer jwbo...@linux.vnet.ibm.com CC: John Williams john.willi...@petalogix.com CC: Michal Simek michal.si...@petalogix.com Signed-off-by: Sadanand M sada...@xilinx.com Signed-off-by: John Linn john.l...@xilinx.com --- drivers/net/Kconfig |5 + drivers/net/Makefile |1 + drivers/net/xilinx_emaclite.c | 1040 + 3 files changed, 1046 insertions(+), 0 deletions(-) create mode 100755 drivers/net/xilinx_emaclite.c diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 5f6509a..84a5120 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1926,6 +1926,11 @@ config ATL2 To compile this driver as a module, choose M here. The module will be called atl2. +config XILINX_EMACLITE + tristate Xilinx 10/100 Ethernet Lite support + help + This driver supports the 10/100 Ethernet Lite from Xilinx. + source drivers/net/fs_enet/Kconfig endif # NET_ETHERNET diff --git a/drivers/net/Makefile b/drivers/net/Makefile index ead8cab..99ae6d7 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -142,6 +142,7 @@ obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o ll_temac-objs := ll_temac_main.o ll_temac_mdio.o obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o +obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o obj-$(CONFIG_QLA3XXX) += qla3xxx.o obj-$(CONFIG_QLGE) += qlge/ diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c new file mode 100755 index 000..3716e20 --- /dev/null +++ b/drivers/net/xilinx_emaclite.c @@ -0,0 +1,1040 @@ +/* + * Xilinx EmacLite Linux driver for the Xilinx Ethernet MAC Lite device. + * + * This is a new flat driver which is based on the original emac_lite + * driver from John Williams john.willi...@petalogix.com. + * + * 2007-2009 (c) Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/module.h +#include linux/uaccess.h +#include linux/init.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/io.h + +#include linux/of_device.h +#include linux/of_platform.h + +#define DRIVER_NAME xilinx_emaclite + +/* Register offsets for the EmacLite Core */ +#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */ +#define XEL_GIER_OFFSET0x07F8 /* GIE Register */ +#define XEL_TSR_OFFSET 0x07FC /* Tx status */ +#define XEL_TPLR_OFFSET0x07F4 /* Tx packet length */ + +#define XEL_RXBUFF_OFFSET 0x1000 /* Receive Buffer */ +#define XEL_RPLR_OFFSET0x100C /* Rx packet length */ +#define XEL_RSR_OFFSET 0x17FC /* Rx status */ + +#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset */ + +/* Global Interrupt Enable Register (GIER) Bit Masks */ +#define XEL_GIER_GIE_MASK 0x8000 /* Global Enable */ + +/* Transmit Status Register (TSR) Bit Masks */ +#define XEL_TSR_XMIT_BUSY_MASK 0x0001 /* Tx complete */ +#define XEL_TSR_PROGRAM_MASK0x0002 /* Program the MAC address */ +#define XEL_TSR_XMIT_IE_MASK0x0008 /* Tx interrupt enable bit */ +#define XEL_TSR_XMIT_ACTIVE_MASK 0x8000/* Buffer is active, SW bit +* only. This is not documented +* in the HW spec */ + +/* Define for programming the MAC address into the EmacLite */ +#define XEL_TSR_PROG_MAC_ADDR (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK) + +/* Receive Status Register (RSR) */ +#define XEL_RSR_RECV_DONE_MASK 0x0001 /* Rx complete */ +#define XEL_RSR_RECV_IE_MASK 0x0008 /* Rx interrupt enable bit */ + +/* Transmit Packet Length Register (TPLR) */ +#define XEL_TPLR_LENGTH_MASK 0x /* Tx packet length */ + +/* Receive Packet Length Register (RPLR) */ +#define XEL_RPLR_LENGTH_MASK 0x /* Rx packet length */ + +#define XEL_HEADER_OFFSET 12 /* Offset to length field */ +#define XEL_HEADER_SHIFT 16 /* Shift value for length */ + +/* General Ethernet Definitions */ +#define XEL_ARP_PACKET_SIZE28 /* Max ARP packet size */ +#define XEL_HEADER_IP_LENGTH_OFFSET16 /* IP Length Offset */ + + + +#define TX_TIMEOUT (60*HZ) /* Tx timeout is 60 seconds. */ +#define ALIGNMENT 4 + +/* BUFFER_ALIGN(adr) calculates the number
2.6.30 kernel panic with any network driver
I just merged in 2.6.30 into our tree and I'm seeing this only when I have a network driver built into the kernel, and it doesn't seem to matter which network driver. Maybe I missed something I need to update in our network drivers to match the kernel. Thanks for any help, John console [ttyS0] enabled brd: module loaded loop: module loaded Unable to handle kernel paging request for data at address 0x75686369 Faulting instruction address: 0xc01c3e34 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT Xilinx Virtex440 Modules linked in: NIP: c01c3e34 LR: c01c2ab4 CTR: REGS: cf831dc0 TRAP: 0300 Not tainted (2.6.30) MSR: 00029000 EE,ME,CE CR: 84284324 XER: 4020 DEAR: 75686369, ESR: TASK = cf82f8a0[1] 'swapper' THREAD: cf83 GPR00: c01c2ab4 cf831e70 cf82f8a0 cf87b3a8 c034e5a4 c01c2a80 0001 GPR08: cfbe69d8 c034dd98 0f2b cf821778 84284342 fd9781f4 f6f6dff7 6ade GPR16: d7f40173 bbd35ff7 3ef7fbff fff5d3f7 0059dac0 006f GPR24: 0001 c034dd98 cf0416e0 cf87b3a0 cf87b3dc c034e5a4 75686369 NIP [c01c3e34] platform_match+0x20/0xa8 LR [c01c2ab4] __driver_attach+0x34/0xa8 Call Trace: [cf831e70] [c027a394] klist_next+0x10c/0x120 (unreliable) [cf831e90] [c01c2ab4] __driver_attach+0x34/0xa8 [cf831eb0] [c01c123c] bus_for_each_dev+0x5c/0x98 [cf831ee0] [c01c243c] driver_attach+0x24/0x34 [cf831ef0] [c01c2050] bus_add_driver+0x18c/0x264 [cf831f10] [c01c2fa8] driver_register+0x6c/0x170 [cf831f30] [c031f8cc] xemaclite_init+0x1c/0x4c [cf831f50] [c00011ac] do_one_initcall+0x34/0x1a0 [cf831fd0] [c0307848] kernel_init+0xa0/0x104 [cf831ff0] [c000e188] kernel_thread+0x4c/0x68 Instruction dump: This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fbdev/xilinxfb: Fix improper casting and tighen up probe path
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Friday, June 12, 2009 11:57 AM
To: linuxppc-...@ozlabs.org; linux-ker...@vger.kernel.org;
b...@kernel.crashing.org; John Linn
Subject: [PATCH] fbdev/xilinxfb: Fix improper casting and tighen up
probe path
From: Grant Likely grant.lik...@secretlab.ca
The xilinxfb driver is improperly casting a physical address to a
u32, and the probe routine isn't as straight forward as it could be.
(discovered by gcc spitting out warnings on most recent change to
xilinxfb driver).
This patch fixes the cast and simplifies the probe path.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
John, can you please test and verify this fix is correct?
I will try to test it today.
-- John
Thanks,
g.
drivers/video/xilinxfb.c | 59
++
1 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 7a868bd..b68b331 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -124,7 +124,6 @@ struct xilinxfb_drvdata {
registers */
dcr_host_t dcr_host;
- unsigned intdcr_start;
unsigned intdcr_len;
void*fb_virt; /* virt. address of the frame
buffer */
@@ -325,8 +324,8 @@ static int xilinxfb_assign(struct device *dev,
drvdata-regs);
}
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, fb: phys=%p, virt=%p, size=%x\n,
- (void *)drvdata-fb_phys, drvdata-fb_virt, fbsize);
+ dev_dbg(dev, fb: phys=%llx, virt=%p, size=%x\n,
+ (unsigned long long)drvdata-fb_phys, drvdata-fb_virt,
fbsize);
return 0; /* success */
@@ -404,9 +403,7 @@ xilinxfb_of_probe(struct of_device *op, const
struct of_device_id *match)
u32 tft_access;
struct xilinxfb_platform_data pdata;
struct resource res;
- int size, rc;
- int start = 0, len = 0;
- dcr_host_t dcr_host;
+ int size, rc, start;
struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
@@ -414,35 +411,39 @@ xilinxfb_of_probe(struct of_device *op, const
struct of_device_id *match)
dev_dbg(op-dev, xilinxfb_of_probe(%p, %p)\n, op, match);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(op-dev, Couldn't allocate device private
record\n);
+ return -ENOMEM;
+ }
+
/*
* To check whether the core is connected directly to DCR or PLB
* interface and initialize the tft_access accordingly.
*/
p = (u32 *)of_get_property(op-node, xlnx,dcr-splb-slave-if,
NULL);
-
- if (p)
- tft_access = *p;
- else
- tft_access = 0; /* For backward compatibility */
+ tft_access = p ? *p : 0;
/*
* Fill the resource structure if its direct PLB interface
* otherwise fill the dcr_host structure.
*/
if (tft_access) {
+ drvdata-flags |= PLB_ACCESS_FLAG;
rc = of_address_to_resource(op-node, 0, res);
if (rc) {
dev_err(op-dev, invalid address\n);
- return -ENODEV;
+ goto err;
}
-
} else {
+ res.start = 0;
start = dcr_resource_start(op-node, 0);
- len = dcr_resource_len(op-node, 0);
- dcr_host = dcr_map(op-node, start, len);
- if (!DCR_MAP_OK(dcr_host)) {
- dev_err(op-dev, invalid address\n);
- return -ENODEV;
+ drvdata-dcr_len = dcr_resource_len(op-node, 0);
+ drvdata-dcr_host = dcr_map(op-node, start,
drvdata-len);
+ if (!DCR_MAP_OK(drvdata-dcr_host)) {
+ dev_err(op-dev, invalid DCR address\n);
+ goto err;
}
}
@@ -467,26 +468,12 @@ xilinxfb_of_probe(struct of_device *op, const
struct of_device_id *match)
if (of_find_property(op-node, rotate-display, NULL))
pdata.rotate_screen = 1;
- /* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata) {
- dev_err(op-dev, Couldn't allocate device private
record\n);
- return -ENOMEM;
- }
dev_set_drvdata(op-dev, drvdata);
+ return xilinxfb_assign(op-dev, drvdata, res.start, pdata);
- if (tft_access)
- drvdata-flags |= PLB_ACCESS_FLAG;
-
- /* Arguments are passed based on the interface */
- if (drvdata-flags PLB_ACCESS_FLAG) {
- return xilinxfb_assign(op-dev, drvdata, res.start,
pdata
RE: [PATCH] fbdev/xilinxfb: Fix improper casting and tighen up probe path
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Friday, June 12, 2009 11:57 AM
To: linuxppc-...@ozlabs.org; linux-ker...@vger.kernel.org;
b...@kernel.crashing.org; John Linn
Subject: [PATCH] fbdev/xilinxfb: Fix improper casting and tighen up
probe path
From: Grant Likely grant.lik...@secretlab.ca
The xilinxfb driver is improperly casting a physical address to a
u32, and the probe routine isn't as straight forward as it could be.
(discovered by gcc spitting out warnings on most recent change to
xilinxfb driver).
This patch fixes the cast and simplifies the probe path.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
John, can you please test and verify this fix is correct?
After a small fix to get it to compile, I did some quick testing with
DCR and without and
it's working fine on the ML507.
-- John
Here's the small change to get it to compile.
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index e3d2992..596157c 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -441,7 +441,7 @@ xilinxfb_of_probe(struct of_device *op, const struct
of_device_id *match)
res.start = 0;
start = dcr_resource_start(op-node, 0);
drvdata-dcr_len = dcr_resource_len(op-node, 0);
- drvdata-dcr_host = dcr_map(op-node, start,
drvdata-len);
+ drvdata-dcr_host = dcr_map(op-node, start,
drvdata-dcr_len);
if (!DCR_MAP_OK(drvdata-dcr_host)) {
dev_err(op-dev, invalid DCR address\n);
goto err;
--
Thanks,
g.
drivers/video/xilinxfb.c | 59
++
1 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 7a868bd..b68b331 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -124,7 +124,6 @@ struct xilinxfb_drvdata {
registers */
dcr_host_t dcr_host;
- unsigned intdcr_start;
unsigned intdcr_len;
void*fb_virt; /* virt. address of the frame
buffer */
@@ -325,8 +324,8 @@ static int xilinxfb_assign(struct device *dev,
drvdata-regs);
}
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, fb: phys=%p, virt=%p, size=%x\n,
- (void *)drvdata-fb_phys, drvdata-fb_virt, fbsize);
+ dev_dbg(dev, fb: phys=%llx, virt=%p, size=%x\n,
+ (unsigned long long)drvdata-fb_phys, drvdata-fb_virt,
fbsize);
return 0; /* success */
@@ -404,9 +403,7 @@ xilinxfb_of_probe(struct of_device *op, const
struct of_device_id *match)
u32 tft_access;
struct xilinxfb_platform_data pdata;
struct resource res;
- int size, rc;
- int start = 0, len = 0;
- dcr_host_t dcr_host;
+ int size, rc, start;
struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
@@ -414,35 +411,39 @@ xilinxfb_of_probe(struct of_device *op, const
struct of_device_id *match)
dev_dbg(op-dev, xilinxfb_of_probe(%p, %p)\n, op, match);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(op-dev, Couldn't allocate device private
record\n);
+ return -ENOMEM;
+ }
+
/*
* To check whether the core is connected directly to DCR or PLB
* interface and initialize the tft_access accordingly.
*/
p = (u32 *)of_get_property(op-node, xlnx,dcr-splb-slave-if,
NULL);
-
- if (p)
- tft_access = *p;
- else
- tft_access = 0; /* For backward compatibility */
+ tft_access = p ? *p : 0;
/*
* Fill the resource structure if its direct PLB interface
* otherwise fill the dcr_host structure.
*/
if (tft_access) {
+ drvdata-flags |= PLB_ACCESS_FLAG;
rc = of_address_to_resource(op-node, 0, res);
if (rc) {
dev_err(op-dev, invalid address\n);
- return -ENODEV;
+ goto err;
}
-
} else {
+ res.start = 0;
start = dcr_resource_start(op-node, 0);
- len = dcr_resource_len(op-node, 0);
- dcr_host = dcr_map(op-node, start, len);
- if (!DCR_MAP_OK(dcr_host)) {
- dev_err(op-dev, invalid address\n);
- return -ENODEV;
+ drvdata-dcr_len = dcr_resource_len(op-node, 0);
+ drvdata-dcr_host = dcr_map(op-node, start,
drvdata-len);
+ if (!DCR_MAP_OK(drvdata-dcr_host)) {
+ dev_err(op-dev, invalid DCR address\n
RE: SD card over (xilinx_)SPI, timeout error while CID
-Original Message-
From: Joachim Foerster [mailto:j...@gmx.de]
Sent: Friday, June 05, 2009 9:34 AM
To: linuxppc-...@ozlabs.org; John Linn;
dbrown...@users.sourceforge.net
Cc: lor...@missinglinkelectronics.com;
joac...@missinglinkelectronics.com
Subject: SD card over (xilinx_)SPI, timeout error while CID
Hi,
we have a very strange problem with SD-card-over-SPI support using
2.6.29.4 on our custom PowerPC 405 (Virtex-4 FX FPGA) based board. To
summarize the problem in one sentence: mmc_spi gets a timeout (error
-110) after sending MMC command CMD10 (CID, card identification?).
The attached log file shows device registration messages during bootup
and debug/error messages after inserting a SD card.
ATM we are migrating from 2.6.26 (old arch/ppc-based, non-device-tree)
to the already mentioned version 2.6.29.4 (arch/powerpc, device tree).
We use Xilinx' opb_spi core (v1.00.e, EDK 9.1.02i) inside the FPGA,
which is connected to a SD card slot. With our old 2.6.26 kernel, SD
cards _are working fine_!.
To solve the problem, among other things, we tried 2.6.26+arch/powerpc
(applying only necessary patches to support/include SPI, MMC OF
bindings) - but the result is the same (error -110). The same is also
true for
2.6.28+arch/powerpc and Linus-HEAD+arch/powerpc . Then we checked
these
patches, which add OF bindings for
SPI/MMC/..., line by line and did not find any hint.
For debugging we added a lot of printks ;-) and noticed that then
there
are less timeouts (error -110), but CRC check errors (-EILSEQ,
mmc_spi.c, mmc_spi_readblock) happen - maybe even signal
shifts/sampling
errors?
To complete confusion :-( the same setup (xilinx_spi+opb_spi) using an
ADS7846 touchscreen controller as SPI slave _does work_ correctly
Our current guess is, that it could be a more basic (?) error in
arch/powerpc . But we have no lead ATM.
Any hints? Does anybody use SD card support with mmc_spi+xilinx_spi ?
There were definitely some changes to the spi driver as I had to make it
use the device tree.
I have not tested with SD as I don't have a board with SD memory. I have
only tested
with a serial eeprom.
Sorry not much help. If I had to guess I would also think it might be
device tree related.
-- John
Joachim
--
for reference: relevant DTS entry:
opb_spi_0: s...@4124 {
#address-cells = 1;
#size-cells = 0;
compatible = xlnx,opb-spi-1.00.e;
reg = 0x4124 0x1;
interrupt-parent = opb_intc_0;
interrupts = 7 2;
xlnx,depth = 0x10;
xlnx,dev-blk-id = 0x4;
xlnx,dev-mir-enable = 0x0;
xlnx,family = virtex4;
xlnx,fifo-exist = 0x1;
xlnx,interrupt-present = 0x1;
xlnx,ip-reg-bar-offset = 0x60;
xlnx,num-bits-reg = 0x8;
xlnx,num-bits-sr = 0x8;
xlnx,num-offchip-ss-bits = 0x0;
xlnx,num-ss-bits = 0x1;
xlnx,occupancy-num-bits = 0x4;
xlnx,spi-slave-only = 0x0;
mmc-s...@0 {
compatible = mmc-spi-slot;
reg = 0;
gpios = opb_gpio_1 0 1;
voltage-ranges = 3300 3300;
spi-max-frequency = 625;
};
};
dmesg during boot sequence, messages concerning SPI and MMC/SD only:
[ 30.677087] xilinx-xps-spi 4124.spi: at 0x4124 mapped to
0xC904, irq=18
[ 30.875967] mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no
poweroff,
cd polling
dmesg after inserting a SD card:
[ 105.375146] mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width
0
timing 0
[ 105.381246] mmc_spi spi32766.0: mmc_spi: power up (21)
[ 105.388286] mmc0: clock 40Hz busmode 2 powermode 2 cs 1 Vdd 21
width 0 timing 0
[ 105.394839] mmc_spi spi32766.0: mmc_spi: power on (21)
[ 105.400197] mmc_spi spi32766.0: xilinx_spi_setup, unsupported mode
bits 4
[ 105.406601] mmc_spi spi32766.0: can't change chip-select polarity
[ 105.414666] mmc0: starting CMD0 arg flags 00c0
[ 105.419176] mmc_spi spi32766.0: mmc_spi: CMD0, resp R1
[ 105.424511] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
nsec/bit
[ 105.431557] mmc0: req done (CMD0): 0: 0001
[ 105.439251] mmc0: starting CMD8 arg 01aa flags 02f5
[ 105.443770] mmc_spi spi32766.0: mmc_spi: CMD8, resp R3/R4/R7
[ 105.449740] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
nsec/bit
[ 105.456789] mmc0: req done (CMD8): 0: 0001 01aa
[ 105.463502] mmc0: starting CMD5 arg flags 02e1
[ 105.468999] mmc_spi spi32766.0: mmc_spi: CMD5, resp R3/R4/R7
[ 105.474968] mmc_spi spi32766.0: ... CMD5 response SPI_R3/R4/R:
resp
0005
[ 105.482448] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
nsec/bit
[ 105.489606] mmc0: req done (CMD5): -22: 0005
[ 105.496511] mmc0: starting CMD55 arg flags 00f5
[ 105.502092] mmc_spi
RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
-Original Message- From: Stephen Neuendorffer Sent: Sunday, April 19, 2009 11:52 PM To: John Williams; microblaze-ucli...@itee.uq.edu.au Cc: grant.lik...@secretlab.ca; linuxppc-dev; linux-ker...@vger.kernel.org; John Linn Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze My thinking is that these drivers are likely to be used as a group, hence it would be nice to make it easy to get them all visible/enabled somehow. Steve It seems like John's suggestion of no arch filters would satisfy that also. Since FPGAs are used in so many different applications this would seem to open the drivers up to everyone regardless of what processor they're using. It's certainly less complex so I like it in that way. But maybe I'm missing something here and there's a downside? -- John -Original Message- From: John Williams [mailto:john.willi...@petalogix.com] Sent: Sun 4/19/2009 4:03 PM To: microblaze-ucli...@itee.uq.edu.au Cc: grant.lik...@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-ker...@vger.kernel.org; John Linn Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer stephen.neuendorf...@gmail.com wrote: On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: Can we have XILINX_DRIVERS, please? That way this can also be enabled on any architecture that has FPGA peripherals. I've thought about this more, and I'd really rather not. The list of affected drivers is short and is not a large maintenance burden. I don't think a list of 2 or 3 architecture selects for each driver is unreasonable. A XILINX_DRIVERS config item doesn't really help much anyway. At any given time one of these drivers may be needed on another platform. ie. the SystemACE device is present on at least one non-virtex, non-spartan platform. Which is exactly why having it architecture dependent isn't right... All of these drivers could be needed and used on any OF-based platform. If you have a platform (for instance, a processor connected to an FPGA which has these peripherals in the FPGA) then you should be able to enable these drivers. Just my 2 cents... What about the radical approach of having NO architecture filters/selectors? Even if some random i386 user selects one of these drivers, so what? It will still compile cleanly (if it doesn't we have to fix it), but there'll be no platform_device_register() call in their machine startup to actually cause driver / device binding. No harm, no foul. Problem goes away. Then, as Grant points out, the rare cases where non-Xilinx platforms do use this stuff, they'll presumably know what they're doing and it's their responsibility to register the appropriate platform_device structures and make the magic happen. John -- John Williams, PhD, B.Eng, B.IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
Josh, any thoughts on putting this into head_44x.S? Thanks, John From: linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org [mailto:linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org] On Behalf Of Tirumala Reddy Marri Sent: Wednesday, April 15, 2009 10:24 AM To: John Linn; jwbo...@linux.vnet.ibm.com; grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org Subject: RE: Question about DBCR0 initialization for 440 Some debuggers like BDI(Abatron) they setup the debug registers. If you have different debugger which doesn't support configuring debug registers I suggest you to program then in the head_44x.S file. From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of John Linn Sent: Tuesday, April 14, 2009 1:33 PM To: jwbo...@linux.vnet.ibm.com; grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org Subject: Question about DBCR0 initialization for 440 The kernel does not initialize the PPC440 DBCR0 register. This prevents (among other things) the use of software breakpoints with GDB. I realize that boot loaders probably do initialize this but we run a lot without a boot loader and so do our customers. The file, head_fsl_booke.S, does initialize the register for the freescale specific code (as shown at the end of the message). We are needing this also for Xilinx. What's the best method to incorporate this, is it possible to add to head_44x.S? Thanks, John #if !defined(CONFIG_BDI_SWITCH) /* * The Abatron BDI JTAG debugger does not tolerate others * mucking with the debug registers. */ lis r2,dbcr0_...@h mtspr SPRN_DBCR0,r2 isync /* clear any residual debug events */ li r2,-1 mtspr SPRN_DBSR,r2 #endif This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
Thanks everyone, will do. -Original Message- From: Grant Likely [mailto:grant.lik...@secretlab.ca] Sent: Friday, April 17, 2009 12:58 PM To: Josh Boyer Cc: John Linn; Tirumala Reddy Marri; linuxppc-dev@ozlabs.org; holl...@us.ibm.com Subject: Re: Question about DBCR0 initialization for 440 Hey John We just discussed this on IRC. Go ahead and generate a patch to unconditionally turn on DBCR0[IDM] in head_44x.S. Don't even bother wrapping it in an #ifdef CONFIG_somthing block. It should be safe, but we'll throw it into -next and see if anyone complains. If it does cause problems, then it can be reworked to something a wee bit more conservative. g. On Fri, Apr 17, 2009 at 11:22 AM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: On Fri, Apr 17, 2009 at 11:46 AM, John Linn john.l...@xilinx.com wrote: Josh, any thoughts on putting this into head_44x.S? The code in the fsl file looks like the right solution. I do have an odd question though, in that it's hard for the kernel to really know if something like a BDI is running. Namely, that config option doesn't cover RiscWatch in an obvious manner. I also wonder if it's possible to have a host system be setting those registers in a guest KVM system so the guest could be debugged with gdb... Hollis, any idea on that? josh -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
-Original Message- From: Grant Likely [mailto:grant.lik...@secretlab.ca] Sent: Friday, April 17, 2009 1:10 PM To: Benjamin Herrenschmidt Cc: Hollis Blanchard; linuxppc-dev@ozlabs.org; John Linn; Tirumala Reddy Marri Subject: Re: Question about DBCR0 initialization for 440 On Fri, Apr 17, 2009 at 1:04 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote: On Friday 17 April 2009 12:22:37 Josh Boyer wrote: On Fri, Apr 17, 2009 at 11:46 AM, John Linn john.l...@xilinx.com wrote: Josh, any thoughts on putting this into head_44x.S? The code in the fsl file looks like the right solution. I do have an odd question though, in that it's hard for the kernel to really know if something like a BDI is running. Namely, that config option doesn't cover RiscWatch in an obvious manner. Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you can't support both a JTAG debugger and hardware breakpoints in the same binary? Now that's an annoying restriction. Might be worth checking if external debug is enabled, and override it only if it's not. ppc440x5_um.pdf says that both can be enabled. The code that I started the thread with, from the fsl file, has conditional for the BDI around it. We think that we still need that conditional as the code is not Oring in the enable such that it would disable external debug mode for the BDI. But we need it this way for our Xilinx pod. #if !defined(CONFIG_BDI_SWITCH) /* * The Abatron BDI JTAG debugger does not tolerate others * mucking with the debug registers. */ lis r2,dbcr0_...@h mtspr SPRN_DBCR0,r2 isync /* clear any residual debug events */ li r2,-1 mtspr SPRN_DBSR,r2 #endif g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
-Original Message- From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com] Sent: Friday, April 17, 2009 2:36 PM To: John Linn Cc: grant.lik...@secretlab.ca; Benjamin Herrenschmidt; linuxppc-dev@ozlabs.org; Hollis Blanchard; Tirumala Reddy Marri Subject: Re: Question about DBCR0 initialization for 440 On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote: Might be worth checking if external debug is enabled, and override it only if it's not. ppc440x5_um.pdf says that both can be enabled. The code that I started the thread with, from the fsl file, has conditional for the BDI around it. We think that we still need that conditional as the code is not Oring in the enable such that it would disable external debug mode for the BDI. But we need it this way for our Xilinx pod. EDM is a read-only bit according to the docs I have. You can't set it (or clear it) at all. It's only set by external hardware. That's strange, my 440x4_um.pdf does not say it's read-only unless it's in some obscure place. josh This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.
Added compatibility for ml507 dvi core.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - cleanup based on review
V3 - update to be based on top of tree rather than Xilinx tree, sorry for the
confusion with this, update the name of the patch slightly to be more accurate
V4 - update based on Grant's comments to simplify it, the binding wasn't changed
as the conversation seemed to verify it's acceptable
V5 - I guess I didn't read the binding conversation thread well, my apologies,
it's now changed to not use the dcr-splb-slave-if property.
drivers/video/xilinxfb.c | 260 +-
1 files changed, 118 insertions(+), 142 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 40a3a2a..43db758 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -24,33 +24,38 @@
#include linux/device.h
#include linux/module.h
#include linux/kernel.h
+#include linux/version.h
#include linux/errno.h
#include linux/string.h
#include linux/mm.h
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#include linux/platform_device.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
+#include asm/dcr.h
#define DRIVER_NAMExilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -111,8 +116,14 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
- u32 regs_phys; /* phys. address of the control
registers */
- u32 __iomem *regs; /* virt. address of the control
registers */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
+ dcr_host_t dcr_host;
+ unsigned intdcr_start;
+ unsigned intdcr_len;
void*fb_virt; /* virt. address of the frame buffer */
dma_addr_t fb_phys;/* phys. address of the frame buffer */
@@ -128,14 +139,18 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call
RE: Question about DBCR0 initialization for 440
-Original Message- From: Hollis Blanchard [mailto:holl...@us.ibm.com] Sent: Friday, April 17, 2009 2:50 PM To: John Linn Cc: grant.lik...@secretlab.ca; Benjamin Herrenschmidt; linuxppc-dev@ozlabs.org; Tirumala Reddy Marri Subject: Re: Question about DBCR0 initialization for 440 On Friday 17 April 2009 15:30:45 John Linn wrote: We think that we still need that conditional as the code is not Oring in the enable such that it would disable external debug mode for the BDI. But we need it this way for our Xilinx pod. #if !defined(CONFIG_BDI_SWITCH) /* * The Abatron BDI JTAG debugger does not tolerate others * mucking with the debug registers. */ lis r2,dbcr0_...@h mtspr SPRN_DBCR0,r2 isync /* clear any residual debug events */ li r2,-1 mtspr SPRN_DBSR,r2 #endif So change the code to OR in your bits. What's the problem? The Xilinx pod uses external mode and we don't want it set when running Linux on the board. It is targeted more to stand alone (non-OS) applications with different debug requirements. -- Hollis Blanchard IBM Linux Technology Center This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.
Added compatibility for ml507 dvi core.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - cleanup based on review
V3 - update to be based on top of tree rather than Xilinx tree, sorry for the
confusion with this, update the name of the patch slightly to be more accurate
V4 - update based on Grant's comments to simplify it, the binding wasn't changed
as the conversation seemed to verify it's acceptable
drivers/video/xilinxfb.c | 282 +++---
1 files changed, 142 insertions(+), 140 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 40a3a2a..ebb9d1c 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -24,33 +24,38 @@
#include linux/device.h
#include linux/module.h
#include linux/kernel.h
+#include linux/version.h
#include linux/errno.h
#include linux/string.h
#include linux/mm.h
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#include linux/platform_device.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
+#include asm/dcr.h
#define DRIVER_NAMExilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -107,12 +112,21 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
- u32 regs_phys; /* phys. address of the control
registers */
- u32 __iomem *regs; /* virt. address of the control
registers */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
+ dcr_host_t dcr_host;
+ unsigned intdcr_start;
+ unsigned intdcr_len;
void*fb_virt; /* virt. address of the frame buffer */
dma_addr_t fb_phys;/* phys. address of the frame buffer */
@@ -128,14 +142,18 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus
RE: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
Sounds good, I'll spin it again with those changes.
-- John
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Thursday, April 16, 2009 1:02 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net;
akonova...@ru.mvista.com;
adap...@gmail.com; jwbo...@linux.vnet.ibm.com; Suneel Garapati; Stephen
Neuendorffer
Subject: Re: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and
cleanup DCR
On Thu, Apr 16, 2009 at 10:26 AM, John Linn john.l...@xilinx.com wrote:
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.
Added compatibility for ml507 dvi core.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - cleanup based on review
V3 - update to be based on top of tree rather than Xilinx tree, sorry for
the
confusion with this, update the name of the patch slightly to be more
accurate
V4 - update based on Grant's comments to simplify it, the binding wasn't
changed
as the conversation seemed to verify it's acceptable
Actually Stephen and I agreed that the driver should *not* go looking
for the xlnx,dcr-splb-slave-if property. reg and dcr-reg are
sufficient. If a driver has both properties, then either method of
access will work.
@@ -107,12 +112,21 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
+
Also, this define is no longer required.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V3] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.
Added compatibility for ml507 dvi core.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - cleanup based on review
V3 - update to be based on top of tree rather than Xilinx tree, sorry for the
confusion with this, update the name of the patch slightly to be more accurate
drivers/video/xilinxfb.c | 295 --
1 files changed, 154 insertions(+), 141 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 40a3a2a..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -24,33 +24,38 @@
#include linux/device.h
#include linux/module.h
#include linux/kernel.h
+#include linux/version.h
#include linux/errno.h
#include linux/string.h
#include linux/mm.h
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#include linux/platform_device.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
+#include asm/dcr.h
#define DRIVER_NAMExilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -107,17 +112,28 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
- u32 regs_phys; /* phys. address of the control
registers */
- u32 __iomem *regs; /* virt. address of the control
registers */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
+ dcr_host_t dcr_host;
+ unsigned intdcr_start;
+ unsigned intdcr_len;
void*fb_virt; /* virt. address of the frame buffer */
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u8 flags; /* features of the driver */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -128,14 +144,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS
Question about DBCR0 initialization for 440
The kernel does not initialize the PPC440 DBCR0 register. This prevents (among other things) the use of software breakpoints with GDB. I realize that boot loaders probably do initialize this but we run a lot without a boot loader and so do our customers. The file, head_fsl_booke.S, does initialize the register for the freescale specific code (as shown at the end of the message). We are needing this also for Xilinx. What's the best method to incorporate this, is it possible to add to head_44x.S? Thanks, John #if !defined(CONFIG_BDI_SWITCH) /* * The Abatron BDI JTAG debugger does not tolerate others * mucking with the debug registers. */ lis r2,dbcr0_...@h mtspr SPRN_DBCR0,r2 isync /* clear any residual debug events */ li r2,-1 mtspr SPRN_DBSR,r2 #endif This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
I thought it was based on mainline, but I now see the weirdness you're talking
about. I'll dig in on this and let you know more as I'm confused also.
-- John
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Sunday, April 12, 2009 12:15 AM
To: John Linn
Cc: jwbo...@linux.vnet.ibm.com; linux-fbdev-de...@lists.sourceforge.net;
linuxppc-dev@ozlabs.org;
akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati
Subject: Re: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support
(non-DCR)
What tree is this patch prepared against? The version in mainline
already does PLB access, and doesn't support DCR at all. It appears
that this driver is based on something that does the opposite.
g.
On Fri, Apr 10, 2009 at 3:17 PM, John Linn john.l...@xilinx.com wrote:
From: Suneel sune...@xilinx.com
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213
--
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -31,27 +31,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAME xilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem *regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned int dcr_start;
unsigned int dcr_len;
@@ -120,6 +132,8 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys; /* phys. address of the frame buffer
*/
int fb_alloced; /* Flag, was the fb memory alloced?
*/
+ u8 flags; /* features of the driver */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +144,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple
[PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
From: Suneel sune...@xilinx.com
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213 --
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -31,27 +31,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAMExilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +132,8 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u8 flags; /* features of the driver */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +144,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata-flags PLB_ACCESS_FLAG)
+ out_be32(drvdata-regs + (offset 2), val);
+ else
+ dcr_write(drvdata-dcr_host, offset, val);
+
+}
static int
xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned
blue,
@@ -175,7 +194,8 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
switch (blank_mode) {
case FB_BLANK_UNBLANK:
/* turn on panel */
- xilinx_fb_out_be32(drvdata, REG_CTRL,
drvdata-reg_ctrl_default
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Wednesday, April 08, 2009 7:52 PM To: John Linn Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net; akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati; Suneel Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? Andrei was copied on the patch, we'll see if he has any thoughts about it. Thanks, John -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message-
From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com]
Sent: Thursday, April 09, 2009 6:47 AM
To: John Linn
Cc: grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org;
linux-fbdev-de...@lists.sourceforge.net;
akonova...@ru.mvista.com; adap...@gmail.com; Suneel; Suneel Garapati
Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB
support (non-DCR)
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227
--
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General
Public License
- * version 2. This program is licensed as is without any
warranty of any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
Grant commented, I'll respin it after other comments to leave that
alone.
#define NUM_REGS2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+u32 regs_phys; /* phys. address of the control
+registers */
Is this driver usable on the 440 based Xilinx devices? If
so, is it possible
to have the physical address of the registers above 4GiB, so
is common with
almost all the I/O on the other 440 boards?
It is used on the 440. As Roderick said,
devices are mapped using the 32 bits of address in the Xilinx tools so
it would be best to stay below 4 Gig to my knowledge.
+void __iomem*regs; /* virt. address of the control
+registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +136,10 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the
frame buffer */
int fb_alloced; /* Flag, was the fb
memory alloced? */
+u32 dcr_splb_slave_if;
+/* True, if control interface is
+connected through plb */
+
Do you need a full 32-bit variable for a simple boolean? It
might be best for
structure alignment, but you might want to look at using a
flags variable or
something that could be extended with feature bits in a single word.
It could be a flag I think. This was easy as it mapped to the device
tree property.
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +150,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or
DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
-dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata
*drvdata, u32 offset,
+u32 val)
+{
+if (drvdata-dcr_splb_slave_if == 1)
+out_be32(drvdata-regs + (offset 2), val);
+else
+dcr_write(drvdata-dcr_host, offset, val);
+
+}
static int
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Thursday, April 09, 2009 8:35 AM
To: Roderick Colenbrander
Cc: Josh Boyer; linux-fbdev-de...@lists.sourceforge.net;
adap...@gmail.com; Suneel Garapati; linuxppc-dev@ozlabs.org;
akonova...@ru.mvista.com; John Linn
Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB
support (non-DCR)
On Thu, Apr 9, 2009 at 7:06 AM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer
jwbo...@linux.vnet.ibm.com
wrote:
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227
--
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU
General Public
License
- * version 2. This program is licensed as is without
any warranty of
any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address
of the control
+ registers */
Is this driver usable on the 440 based Xilinx devices? If
so, is it
possible
to have the physical address of the registers above 4GiB,
so is common
with
almost all the I/O on the other 440 boards?
The driver works fine on 440 based Xilinx boards (the ML510
I use has a 440
core). It might be nice to move physical addresses above
4GB for devices but
in all Xilinx tools and reference designs addresses below
4GB are used for
periperhals and I think even below 2GB (or even below 1GB).
It depends on
the design.
Regardless, it is good practice to use phys_addr_t instead of u32 for
physical addresses.
I can change that when I respin to incorporate comments.
Thanks,
John
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message- From: Dale Farnsworth [mailto:d...@farnsworth.org] Sent: Thursday, April 09, 2009 9:36 AM To: John Linn; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) -Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Wednesday, April 08, 2009 7:52 PM To: John Linn Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net; akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati; Suneel Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? Andrei was copied on the patch, we'll see if he has any thoughts about it. Although I work for MontaVista, I don't speak for them on licensing issues. In my opinion, unless someone can come up with a compelling reason for changing the license terms of a file, they shouldn't be changed. MontaVista made a deliberate, considered decision to license that file under GPLv2 and not GPLv2 or later. Those who use and distribute modifications to GPLv2 licensed work need to respect the license. Thanks Dale, we agree, Grant said the same thing. I'll fix that when I respin the patch. -- John -Dale This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227 --
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed as is without any warranty of any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
/*
@@ -31,27 +38,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAMExilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +136,10 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u32 dcr_splb_slave_if;
+ /* True, if control interface is
+ connected through plb */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +150,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata-dcr_splb_slave_if == 1)
+ out_be32(drvdata-regs + (offset 2), val
[PATCH] Powerpc: Xilinx: Intc: Fix level irqs which have duplicates
The interrupt controller was not handling level interrupts correctly
such that duplicate interrupts were happening. This fixes the problem
and adds edge type interrupts which are needed in Xilinx hardware.
Signed-off-by: John Linn john.l...@xilinx.com
---
arch/powerpc/sysdev/xilinx_intc.c | 112 ++---
1 files changed, 103 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index a22e1a2..7c99a1e 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -41,8 +41,30 @@
static struct irq_host *master_irqhost;
+/* The following table allows the interrupt type, edge or level,
+ * to be cached after being read from the device tree until the interrupt
+ * is mapped
+ */
+static int xilinx_intc_typetable[32];
+
+/* Map the interrupt type from the device tree to the interrupt types
+ * used by the interrupt subsystem
+ */
+static unsigned char xilinx_intc_map_senses[] = {
+ IRQ_TYPE_EDGE_RISING,
+ IRQ_TYPE_EDGE_FALLING,
+ IRQ_TYPE_LEVEL_HIGH,
+ IRQ_TYPE_LEVEL_LOW,
+};
+
/*
- * IRQ Chip operations
+ * The interrupt controller is setup such that it doesn't work well with
+ * the level interrupt handler in the kernel because the handler acks the
+ * interrupt before calling the application interrupt handler. To deal with
+ * that, we use 2 different irq chips so that different functions can be
+ * used for level and edge type interrupts.
+ *
+ * IRQ Chip common (across level and edge) operations
*/
static void xilinx_intc_mask(unsigned int virq)
{
@@ -52,15 +74,54 @@ static void xilinx_intc_mask(unsigned int virq)
out_be32(regs + XINTC_CIE, 1 irq);
}
-static void xilinx_intc_unmask(unsigned int virq)
+static int xilinx_intc_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct irq_desc *desc = get_irq_desc(virq);
+
+ desc-status = ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
+ desc-status |= flow_type IRQ_TYPE_SENSE_MASK;
+ if (flow_type (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
+ desc-status |= IRQ_LEVEL;
+ return 0;
+}
+
+/*
+ * IRQ Chip level operations
+ */
+static void xilinx_intc_level_unmask(unsigned int virq)
{
int irq = virq_to_hw(virq);
void * regs = get_irq_chip_data(virq);
pr_debug(unmask: %d\n, irq);
out_be32(regs + XINTC_SIE, 1 irq);
+
+ /* ack level irqs because they can't be acked during
+* ack function since the handle_level_irq function
+* acks the irq before calling the inerrupt handler
+*/
+ out_be32(regs + XINTC_IAR, 1 irq);
+}
+
+static struct irq_chip xilinx_intc_level_irqchip = {
+ .typename = Xilinx Level INTC,
+ .mask = xilinx_intc_mask,
+ .mask_ack = xilinx_intc_mask,
+ .unmask = xilinx_intc_level_unmask,
+ .set_type = xilinx_intc_set_type,
+};
+
+/*
+ * IRQ Chip edge operations
+ */
+static void xilinx_intc_edge_unmask(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void *regs = get_irq_chip_data(virq);
+ pr_debug(unmask: %d\n, irq);
+ out_be32(regs + XINTC_SIE, 1 irq);
}
-static void xilinx_intc_ack(unsigned int virq)
+static void xilinx_intc_edge_ack(unsigned int virq)
{
int irq = virq_to_hw(virq);
void * regs = get_irq_chip_data(virq);
@@ -68,27 +129,60 @@ static void xilinx_intc_ack(unsigned int virq)
out_be32(regs + XINTC_IAR, 1 irq);
}
-static struct irq_chip xilinx_intc_irqchip = {
- .typename = Xilinx INTC,
+static struct irq_chip xilinx_intc_edge_irqchip = {
+ .typename = Xilinx Edge INTC,
.mask = xilinx_intc_mask,
- .unmask = xilinx_intc_unmask,
- .ack = xilinx_intc_ack,
+ .unmask = xilinx_intc_edge_unmask,
+ .ack = xilinx_intc_edge_ack,
+ .set_type = xilinx_intc_set_type,
};
/*
* IRQ Host operations
*/
+
+/**
+ * xilinx_intc_xlate - translate virq# from device tree interrupts property
+ */
+static int xilinx_intc_xlate(struct irq_host *h, struct device_node *ct,
+ u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_flags)
+{
+ if (intsize != 2)
+ return -1;
+
+ /* keep a copy of the interrupt type til the interrupt is mapped
+*/
+ xilinx_intc_typetable[intspec[0]] = xilinx_intc_map_senses[intspec[1]];
+
+ /* Xilinx uses 2 interrupt entries, the 1st being the h/w
+* interrupt number, the 2nd being the interrupt type, edge or level
+*/
+ *out_hwirq = intspec[0];
+ *out_flags = xilinx_intc_map_senses[intspec[1]];
+
+ return 0;
+}
static int xilinx_intc_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t irq)
{
set_irq_chip_data(virq, h-host_data);
- set_irq_chip_and_handler(virq
RE: Xilinx cygwin linux cross recommendations ?
I agree that VmWare is a reasonable solution. Some of our field guys, that don't do Linux everyday, use the ELDK in a VmWare appliance and this seems reasonable. We never had great luck with cygwin stuff in this area. -- John -Original Message- From: linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org [mailto:linuxppc-dev- bounces+john.linn=xilinx@ozlabs.org] On Behalf Of David H. Lynch Jr. Sent: Thursday, March 19, 2009 5:59 PM To: linuxppc-dev@ozlabs.org Subject: Xilinx cygwin linux cross recommendations ? Does anyone have experience sugestions for building ppc/linux apps or even ppc kernels under windows. I work (and live) under Linux. I am very happy to work under Linux. I only spend about 20 minutes a week in windows anymore. But I have coworkers, and clients that live under windows. Mostly I have them working under coLinux, but even that seems to be too much for many of them. I have been able to mangle my build environment to work under msys and use the xilinx edk cross compiler to build standalone PPC apps, But the libraries do not seem to be present for linux applications. I build my own uclibc crosscompiler under linux from buildroot. Has anyone got experience doing that under windows ? Can I just copy the appropriate library binaries and use them with the xilinx EDK cross compiler ? Presumably I need to match versions of GCC. Other suguestions ? Thanks. -- Dave LynchDLA Systems Software Development: Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Xilinx: SPI: driver not releasing memory
The driver was not releasing memory when it was removed or
when there was a failure during probe. This fixes it.
Signed-off-by: John Linn john.l...@xilinx.com
---
This is an incremental patch to the patch (updated driver
for device tree) that is in the next branch.
---
drivers/spi/xilinx_spi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index fe7e5f3..494d3f7 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -354,7 +354,7 @@ static int __init xilinx_spi_of_probe(struct of_device
*ofdev,
if (xspi-regs == NULL) {
rc = -ENOMEM;
dev_warn(ofdev-dev, ioremap failure\n);
- goto put_master;
+ goto release_mem;
}
xspi-irq = r_irq-start;
@@ -365,7 +365,7 @@ static int __init xilinx_spi_of_probe(struct of_device
*ofdev,
prop = of_get_property(ofdev-node, xlnx,num-ss-bits, len);
if (!prop || len sizeof(*prop)) {
dev_warn(ofdev-dev, no 'xlnx,num-ss-bits' property\n);
- goto put_master;
+ goto unmap_io;
}
master-num_chipselect = *prop;
@@ -397,6 +397,8 @@ free_irq:
free_irq(xspi-irq, xspi);
unmap_io:
iounmap(xspi-regs);
+release_mem:
+ release_mem_region(r_mem-start, resource_size(r_mem));
put_master:
spi_master_put(master);
return rc;
@@ -406,6 +408,7 @@ static int __devexit xilinx_spi_remove(struct of_device
*ofdev)
{
struct xilinx_spi *xspi;
struct spi_master *master;
+ struct resource r_mem;
master = platform_get_drvdata(ofdev);
xspi = spi_master_get_devdata(master);
@@ -413,6 +416,8 @@ static int __devexit xilinx_spi_remove(struct of_device
*ofdev)
spi_bitbang_stop(xspi-bitbang);
free_irq(xspi-irq, xspi);
iounmap(xspi-regs);
+ if (!of_address_to_resource(ofdev-node, 0, r_mem))
+ release_mem_region(r_mem.start, resource_size(r_mem));
dev_set_drvdata(ofdev-dev, 0);
spi_master_put(xspi-bitbang.master);
--
1.5.3.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Linux on Memec Virtex4 FX12 Minimodule
Hi Pawel, Sorry for the delay, I just missed this message. You should really be building arch/powerpc not arch/ppc as no one is going to support that. I realize that's a pain, but arch/ppc has been dead for about 6 months now. http://xilinx.wikidot.com http://xilinx.wikidot.com/ has a lot more information about building the kernel from our GIT tree. You can also post to http://forums.xilinx.com http://forums.xilinx.com/ in the Embedded Linux forum for more Xilinx specific help. I don't understand you're problem either, but I would try building 1st with arch=powerpc and using the ramdisk image that we have on our wiki to get a good baseline. You'll need to generate a device tree for your hardware platform but that's not too hard and is explained on the wiki also. Thanks, John From: linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org [mailto:linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org] On Behalf Of Pawel P. Kusmierski Sent: Tuesday, January 06, 2009 6:02 PM To: linuxppc-dev@ozlabs.org Subject: Linux on Memec Virtex4 FX12 Minimodule This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [powerpc] Xilinx: SPI: updated driver for device tree
The driver was updated to use the device tree rather than the platform data.
Signed-off-by: John Linn [EMAIL PROTECTED]
---
drivers/spi/xilinx_spi.c | 137 +++---
1 files changed, 81 insertions(+), 56 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 68d6f49..fe7e5f3 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -15,12 +15,15 @@
#include linux/init.h
#include linux/interrupt.h
#include linux/platform_device.h
+
+#include linux/of_platform.h
+#include linux/of_device.h
+#include linux/of_spi.h
+
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
#include linux/io.h
-#include syslib/virtex_devices.h
-
#define XILINX_SPI_NAME xilinx_spi
/* Register definitions as per OPB Serial Peripheral Interface (SPI) (v1.00e)
@@ -144,23 +147,14 @@ static int xilinx_spi_setup_transfer(struct spi_device
*spi,
struct spi_transfer *t)
{
u8 bits_per_word;
- u32 hz;
- struct xilinx_spi *xspi = spi_master_get_devdata(spi-master);
bits_per_word = (t) ? t-bits_per_word : spi-bits_per_word;
- hz = (t) ? t-speed_hz : spi-max_speed_hz;
if (bits_per_word != 8) {
dev_err(spi-dev, %s, unsupported bits_per_word=%d\n,
__func__, bits_per_word);
return -EINVAL;
}
- if (hz xspi-speed_hz hz) {
- dev_err(spi-dev, %s, unsupported clock rate %uHz\n,
- __func__, hz);
- return -EINVAL;
- }
-
return 0;
}
@@ -304,32 +298,38 @@ static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int __init xilinx_spi_probe(struct platform_device *dev)
+static int __init xilinx_spi_of_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
{
- int ret = 0;
struct spi_master *master;
struct xilinx_spi *xspi;
- struct xspi_platform_data *pdata;
- struct resource *r;
+ struct resource r_irq_struct;
+ struct resource r_mem_struct;
+
+ struct resource *r_irq = r_irq_struct;
+ struct resource *r_mem = r_mem_struct;
+ int rc = 0;
+ const u32 *prop;
+ int len;
/* Get resources(memory, IRQ) associated with the device */
- master = spi_alloc_master(dev-dev, sizeof(struct xilinx_spi));
+ master = spi_alloc_master(ofdev-dev, sizeof(struct xilinx_spi));
if (master == NULL) {
return -ENOMEM;
}
- platform_set_drvdata(dev, master);
- pdata = dev-dev.platform_data;
+ dev_set_drvdata(ofdev-dev, master);
- if (pdata == NULL) {
- ret = -ENODEV;
+ rc = of_address_to_resource(ofdev-node, 0, r_mem);
+ if (rc) {
+ dev_warn(ofdev-dev, invalid address\n);
goto put_master;
}
- r = platform_get_resource(dev, IORESOURCE_MEM, 0);
- if (r == NULL) {
- ret = -ENODEV;
+ rc = of_irq_to_resource(ofdev-node, 0, r_irq);
+ if (rc == NO_IRQ) {
+ dev_warn(ofdev-dev, no IRQ found\n);
goto put_master;
}
@@ -341,47 +341,57 @@ static int __init xilinx_spi_probe(struct platform_device
*dev)
xspi-bitbang.master-setup = xilinx_spi_setup;
init_completion(xspi-done);
- if (!request_mem_region(r-start,
- r-end - r-start + 1, XILINX_SPI_NAME)) {
- ret = -ENXIO;
+ xspi-irq = r_irq-start;
+
+ if (!request_mem_region(r_mem-start,
+ r_mem-end - r_mem-start + 1, XILINX_SPI_NAME)) {
+ rc = -ENXIO;
+ dev_warn(ofdev-dev, memory request failure\n);
goto put_master;
}
- xspi-regs = ioremap(r-start, r-end - r-start + 1);
+ xspi-regs = ioremap(r_mem-start, r_mem-end - r_mem-start + 1);
if (xspi-regs == NULL) {
- ret = -ENOMEM;
+ rc = -ENOMEM;
+ dev_warn(ofdev-dev, ioremap failure\n);
goto put_master;
}
+ xspi-irq = r_irq-start;
- ret = platform_get_irq(dev, 0);
- if (ret 0) {
- ret = -ENXIO;
- goto unmap_io;
- }
- xspi-irq = ret;
+ /* dynamic bus assignment */
+ master-bus_num = -1;
- master-bus_num = pdata-bus_num;
- master-num_chipselect = pdata-num_chipselect;
- xspi-speed_hz = pdata-speed_hz;
+ /* number of slave select bits is required */
+ prop = of_get_property(ofdev-node, xlnx,num-ss-bits, len);
+ if (!prop || len sizeof(*prop)) {
+ dev_warn(ofdev-dev, no 'xlnx,num-ss-bits' property\n);
+ goto put_master;
+ }
+ master-num_chipselect = *prop;
/* SPI controller initializations */
xspi_init_hw(xspi-regs
[PATCH][V2] [powerpc] GPIO: Adding new Xilinx driver
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya [EMAIL PROTECTED]
Signed-off-by: John Linn [EMAIL PROTECTED]
---
V2 - Updated based on Anton's comments
drivers/gpio/Kconfig | 15 ++--
drivers/gpio/Makefile |1 +
drivers/gpio/xilinx_gpio.c | 235
3 files changed, 244 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 7f2ee27..12a8006 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -65,6 +65,14 @@ config GPIO_SYSFS
# put expanders in the right section, in alphabetical order
+comment Memory mapped GPIO expanders:
+
+config GPIO_XILINX
+ bool Xilinx GPIO support
+ depends on PPC_OF
+ help
+ Say yes here to support the Xilinx FPGA GPIO device
+
comment I2C GPIO expanders:
config GPIO_MAX732X
@@ -127,13 +135,6 @@ config GPIO_PCF857X
This driver provides an in-kernel interface to those GPIOs using
platform-neutral GPIO calls.
-config GPIO_TWL4030
- tristate TWL4030, TWL5030, and TPS659x0 GPIOs
- depends on TWL4030_CORE
- help
- Say yes here to access the GPIO signals of various multi-function
- power management chips from Texas Instruments.
-
comment PCI GPIO expanders:
config GPIO_BT8XX
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6aafdeb..49ac64e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_GPIO_MCP23S08) += mcp23s08.o
obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
+obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index 000..3c1177a
--- /dev/null
+++ b/drivers/gpio/xilinx_gpio.c
@@ -0,0 +1,235 @@
+/*
+ * Xilinx gpio driver
+ *
+ * Copyright 2008 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/errno.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/of_gpio.h
+#include linux/io.h
+#include linux/gpio.h
+
+/* Register Offset Definitions */
+#define XGPIO_DATA_OFFSET (0x0) /* Data register */
+#define XGPIO_TRI_OFFSET(0x4) /* I/O direction register */
+
+struct xgpio_instance {
+ struct of_mm_gpio_chip mmchip;
+ u32 gpio_state; /* GPIO state shadow register */
+ u32 gpio_dir; /* GPIO direction shadow register */
+ spinlock_t gpio_lock; /* Lock used for synchronization */
+};
+
+/**
+ * xgpio_get - Read the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function reads the specified signal of the GPIO device. It returns 0 if
+ * the signal clear, 1 if signal is set or negative value on error.
+ */
+static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return (in_be32(mm_gc-regs + XGPIO_DATA_OFFSET) gpio) 1;
+}
+
+/**
+ * xgpio_set - Write the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ * @val:Value to be written to specified signal.
+ *
+ * This function writes the specified value in to the specified signal of the
+ * GPIO device.
+ */
+static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(chip-gpio_lock, flags);
+
+ /* Write to GPIO signal and set its direction to output */
+ if (val)
+ chip-gpio_state |= 1 gpio;
+ else
+ chip-gpio_state = ~(1 gpio);
+ out_be32(mm_gc-regs + XGPIO_DATA_OFFSET, chip-gpio_state);
+
+ spin_unlock_irqrestore(chip-gpio_lock, flags);
+}
+
+/**
+ * xgpio_dir_in - Set the direction of the specified GPIO signal as input.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function sets the direction of specified GPIO signal as input.
+ * It returns 0 if direction of GPIO signals is set as input otherwise it
+ * returns negative error value.
+ */
+static int
[PATCH] [powerpc] GPIO: Adding new Xilinx driver
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya [EMAIL PROTECTED]
Signed-off-by: John Linn [EMAIL PROTECTED]
---
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/xilinx_gpio.c | 240
3 files changed, 249 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 7f2ee27..f6b0da8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -65,6 +65,14 @@ config GPIO_SYSFS
# put expanders in the right section, in alphabetical order
+comment Memory mapped GPIO expanders:
+
+config GPIO_XILINX
+ bool Xilinx GPIO support
+ depends on OF
+ help
+ Say yes here to support the Xilinx FPGA GPIO device
+
comment I2C GPIO expanders:
config GPIO_MAX732X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6aafdeb..49ac64e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_GPIO_MCP23S08) += mcp23s08.o
obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
+obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index 000..224d0d5
--- /dev/null
+++ b/drivers/gpio/xilinx_gpio.c
@@ -0,0 +1,240 @@
+/*
+ * Xilinx gpio driver
+ *
+ * Copyright 2008 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/of_gpio.h
+#include linux/io.h
+#include linux/gpio.h
+
+/* Register Offset Definitions */
+#define XGPIO_DATA_OFFSET (0x0) /* Data register */
+#define XGPIO_TRI_OFFSET(0x4) /* I/O direction register */
+
+struct xgpio_instance {
+ struct of_mm_gpio_chip mmchip;
+ u32 gpio_state; /* GPIO state shadow register */
+ u32 gpio_dir; /* GPIO direction shadow register */
+ spinlock_t gpio_lock; /* Lock used for synchronization */
+};
+
+/**
+ * xgpio_get - Read the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function reads the specified signal of the GPIO device. It returns 0 if
+ * the signal clear, 1 if signal is set or negative value on error.
+ */
+static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return (in_be32(mm_gc-regs + XGPIO_DATA_OFFSET) gpio) 1;
+}
+
+/**
+ * xgpio_set - Write the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ * @val:Value to be written to specified signal.
+ *
+ * This function writes the specified value in to the specified signal of the
+ * GPIO device.
+ */
+static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(chip-gpio_lock, flags);
+
+ /* Write to GPIO signal and set its direction to output */
+ if (val)
+ chip-gpio_state |= 1 gpio;
+ else
+ chip-gpio_state = ~(1 gpio);
+ out_be32(mm_gc-regs + XGPIO_DATA_OFFSET, chip-gpio_state);
+
+ spin_unlock_irqrestore(chip-gpio_lock, flags);
+}
+
+/**
+ * xgpio_dir_in - Set the direction of the specified GPIO signal as input.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function sets the direction of specified GPIO signal as input.
+ * It returns 0 if direction of GPIO signals is set as input otherwise it
+ * returns negative error value.
+ */
+static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(chip-gpio_lock, flags);
+
+ /* Set the GPIO bit in shadow register and set direction as input */
+ chip-gpio_dir |= (1 gpio);
+ out_be32(mm_gc-regs + XGPIO_TRI_OFFSET, chip-gpio_dir);
+
+ spin_unlock_irqrestore(chip-gpio_lock, flags);
+
+ return 0
RE: Could XUP be uesd as a SMP platform
No, the PowerPC 405s can’t be used as a SMP platform. The 405 caches are not designed with cache coherency for SMP. Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ?? Sent: Wednesday, October 08, 2008 12:49 AM To: linuxppc-dev@ozlabs.org Subject: Could XUP be uesd as a SMP platform Hi all, I am working with a Xilinx Virtex II Pro evaluation board, which has two PowerPC 405 and I have ported linux 2.6.24 onto that board when there is one PPC405 configured. I'd like to use this board as a SMP platform. Is it feasible? If it works, what steps should i follow? Could you give me some recommendations or any literatures I could refer to? Thanks a lot! This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
I was thinking it's CONFIG_PPC_UDBG_16550. -- John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Kumar Gala Sent: Wednesday, August 06, 2008 12:39 PM To: Stephen Neuendorffer Cc: Scott Wood; ppc-dev list Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible Do you know what the CONFIG_ option is called for the legacy driver. - k On Aug 6, 2008, at 1:02 PM, Stephen Neuendorffer wrote: The problem (in my case) is that the legacy-serial driver doesn't accept all of the 16550 configurations accepted by the regular ns16550 driver. The problem is not related to simple-bus, but only became visible when simple-bus bindings are used because the legacy-serial driver specifically looks for an ns16550 node contained by a simple-bus. Most likely the hpcn_defconfig disables the legacy-serial driver altogether. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Scott Wood Sent: Wednesday, August 06, 2008 10:36 AM To: [EMAIL PROTECTED] Cc: ppc-dev list Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. If extra stuff needs to be done, it shouldn't claim to be a simple-bus. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kconfig debug help
I'm trying to debug some Kconfig problems and am looking for a way to get more debug output. I have used KBUILD_VERBOSE=1 on the command line and it didn't help much. I'm seeing an issue with creating a new defconfig file for a board. I get the .config created, then copy it to a defconfig, and then it doesn't do anything when I run make with the defconfig file. Thanks for any help, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kconfig debug help
Thanks Josh, I just came to the conclusion it was busted somehow in the mainline after repeating it there. -- John -Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] On Behalf Of Josh Boyer Sent: Tuesday, August 05, 2008 4:49 PM To: John Linn Cc: linuxppc-dev@ozlabs.org Subject: Re: Kconfig debug help On Tue, 2008-08-05 at 15:37 -0600, John Linn wrote: I'm trying to debug some Kconfig problems and am looking for a way to get more debug output. I have used KBUILD_VERBOSE=1 on the command line and it didn't help much. I'm seeing an issue with creating a new defconfig file for a board. I get the .config created, then copy it to a defconfig, and then it doesn't do anything when I run make with the defconfig file. Yeah, I hit that myself this weekend. It's a bug in the Kconfig area. It's 1/2 fixed in the latest Linus and powerpc trees. josh This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: going to OLS?
Sounds good, I'll be there. It will be good to put some faces to names. Cheers, John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Becky Bruce Sent: Tuesday, July 22, 2008 8:55 AM To: Sean MacLennan; [EMAIL PROTECTED]; Wolfgang Denk; Stefan Roese; Geert Uytterhoeven Cc: linuxppc-dev@ozlabs.org Subject: Re: going to OLS? So, There doesn't seem to be an official plan, so I'm making one Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this evening. Anybody that wants to join us welcome. Cheers, Becky On Jul 21, 2008, at 4:24 PM, Sean MacLennan wrote: On Mon, 21 Jul 2008 14:15:53 -0600 Grant Likely [EMAIL PROTECTED] wrote: BTW, if anyone else wants to receive the contact phone list, then send me your phone number ASAP. I'll be sending it out this evening. My home phone number is 613-728-1680. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Xilinx: PS2: driver updates based on review
Review comments were incorporated to improve the driver.
1. Some data was eliminated that was not needed.
2. Renaming of variables for clarity.
3. Removed unneeded type casting.
4. Changed to use dev_err rather than other I/O.
5. Merged together some functions.
6. Added kerneldoc format to functions.
Signed-off-by: Sadanand [EMAIL PROTECTED]
Signed-off-by: John Linn [EMAIL PROTECTED]
---
This patch is an incremental patch to be applied to
[V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver.
drivers/input/serio/xilinx_ps2.c | 220 +
1 files changed, 125 insertions(+), 95 deletions(-)
diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
index e86f11b..eba46c7 100644
--- a/drivers/input/serio/xilinx_ps2.c
+++ b/drivers/input/serio/xilinx_ps2.c
@@ -58,23 +58,20 @@
/* Mask for all the Receive Interrupts */
#define XPS2_IPIXR_RX_ALL (XPS2_IPIXR_RX_OVF | XPS2_IPIXR_RX_ERR | \
- XPS2_IPIXR_RX_FULL)
+XPS2_IPIXR_RX_FULL)
/* Mask for all the Interrupts */
#define XPS2_IPIXR_ALL (XPS2_IPIXR_TX_ALL | XPS2_IPIXR_RX_ALL | \
- XPS2_IPIXR_WDT_TOUT)
+XPS2_IPIXR_WDT_TOUT)
/* Global Interrupt Enable mask */
#define XPS2_GIER_GIE_MASK 0x8000
struct xps2data {
int irq;
- u32 phys_addr;
- u32 remap_size;
spinlock_t lock;
- u8 rxb; /* Rx buffer */
void __iomem *base_address; /* virt. address of control registers */
- unsigned int dfl;
+ unsigned int flags;
struct serio serio; /* serio */
};
@@ -82,8 +79,13 @@ struct xps2data {
/* XPS PS/2 data transmission calls */
//
-/*
- * xps2_recv() will attempt to receive a byte of data from the PS/2 port.
+/**
+ * xps2_recv() - attempts to receive a byte from the PS/2 port.
+ * @drvdata: pointer to ps2 device private data structure
+ * @byte: address where the read data will be copied
+ *
+ * If there is any data available in the PS/2 receiver, this functions reads
+ * the data, otherwise it returns error.
*/
static int xps2_recv(struct xps2data *drvdata, u8 *byte)
{
@@ -105,7 +107,7 @@ static int xps2_recv(struct xps2data *drvdata, u8 *byte)
/*/
static irqreturn_t xps2_interrupt(int irq, void *dev_id)
{
- struct xps2data *drvdata = (struct xps2data *)dev_id;
+ struct xps2data *drvdata = dev_id;
u32 intr_sr;
u8 c;
int status;
@@ -115,35 +117,28 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
out_be32(drvdata-base_address + XPS2_IPISR_OFFSET, intr_sr);
/* Check which interrupt is active */
- if (intr_sr XPS2_IPIXR_RX_OVF) {
- printk(KERN_ERR %s: receive overrun error\n,
- drvdata-serio.name);
- }
+ if (intr_sr XPS2_IPIXR_RX_OVF)
+ dev_err(drvdata-serio.dev.parent, receive overrun error\n);
if (intr_sr XPS2_IPIXR_RX_ERR)
- drvdata-dfl |= SERIO_PARITY;
+ drvdata-flags |= SERIO_PARITY;
if (intr_sr (XPS2_IPIXR_TX_NOACK | XPS2_IPIXR_WDT_TOUT))
- drvdata-dfl |= SERIO_TIMEOUT;
+ drvdata-flags |= SERIO_TIMEOUT;
if (intr_sr XPS2_IPIXR_RX_FULL) {
- status = xps2_recv(drvdata, drvdata-rxb);
+ status = xps2_recv(drvdata, c);
/* Error, if a byte is not received */
if (status) {
- printk(KERN_ERR
- %s: wrong rcvd byte count (%d)\n,
- drvdata-serio.name, status);
+ dev_err(drvdata-serio.dev.parent,
+ wrong rcvd byte count\n);
} else {
- c = drvdata-rxb;
- serio_interrupt(drvdata-serio, c, drvdata-dfl);
- drvdata-dfl = 0;
+ serio_interrupt(drvdata-serio, c, drvdata-flags);
+ drvdata-flags = 0;
}
}
- if (intr_sr XPS2_IPIXR_TX_ACK)
- drvdata-dfl = 0;
-
return IRQ_HANDLED;
}
@@ -151,8 +146,15 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
/* serio callbacks */
/***/
-/*
- * sxps2_write() sends a byte out through the PS/2 interface.
+/**
+ * sxps2_write() - sends a byte out through the PS/2 port.
+ * @pserio:pointer to the serio structure of the PS/2 port
+ * @c: data that needs to be written to the PS/2 port
+ *
+ * This fucntion checks if the PS/2 transmitter is empty and sends a byte.
+ * Otherwise it returns error. Transmission fails only when nothing is
connected
+ * to the PS/2 port. Thats why, we do not try to resend the data in case
RE: [PATCH] [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver
These look like good comments from Peter. Dmitry, how would you like to do this, would you prefer us to do an incremental patch from the existing patch (V3)? Or a new V4 for the patch? Peter, with regard to the data sheet, I would prefer not to put a specific URL in as things always seem to get moved around so anything beyond xilinx.com would likely be wrong sometime in the future. Thanks, John -Original Message- From: Peter Korsgaard [mailto:[EMAIL PROTECTED] On Behalf Of Peter Korsgaard Sent: Tuesday, July 08, 2008 3:00 AM To: John Linn Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sadanand Mutyala Subject: Re: [PATCH] [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver John == John Linn [EMAIL PROTECTED] writes: Hi, Added a new driver for Xilinx XPS PS2 IP. This driver is a flat driver to better match the Linux driver pattern. Signed-off-by: Sadanand [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] --- V2 Updated the driver based on feedback from Dmitry, Peter, and Grant. We believe Montavista copyright is still valid. V3 Incorporated Dmitry and Grant's 2nd set of comments which were some minor cleanup and removal of the mutex which was not needed. drivers/input/serio/Kconfig |5 + drivers/input/serio/Makefile |1 + drivers/input/serio/xilinx_ps2.c | 384 ++ 3 files changed, 390 insertions(+), 0 deletions(-) create mode 100644 drivers/input/serio/xilinx_ps2.c diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index ec4b661..0e62b39 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -190,4 +190,9 @@ config SERIO_RAW To compile this driver as a module, choose M here: the module will be called serio_raw. +config SERIO_XILINX_XPS_PS2 + tristate Xilinx XPS PS/2 Controller Support + help +This driver supports XPS PS/2 IP from Xilinx EDK. + endif diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile index 38b8868..9b6c813 100644 --- a/drivers/input/serio/Makefile +++ b/drivers/input/serio/Makefile @@ -21,3 +21,4 @@ obj-$(CONFIG_SERIO_PCIPS2) += pcips2.o obj-$(CONFIG_SERIO_MACEPS2) += maceps2.o obj-$(CONFIG_SERIO_LIBPS2)+= libps2.o obj-$(CONFIG_SERIO_RAW) += serio_raw.o +obj-$(CONFIG_SERIO_XILINX_XPS_PS2)+= xilinx_ps2.o diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c new file mode 100644 index 000..e86f11b --- /dev/null +++ b/drivers/input/serio/xilinx_ps2.c @@ -0,0 +1,384 @@ +/* + * Xilinx XPS PS/2 device driver + * + * (c) 2005 MontaVista Software, Inc. + * (c) 2008 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + +#include linux/module.h +#include linux/serio.h +#include linux/interrupt.h +#include linux/errno.h +#include linux/init.h +#include linux/list.h +#include linux/io.h + +#include linux/of_device.h +#include linux/of_platform.h + +#define DRIVER_NAME xilinx_ps2 + Is there an online datasheet available somewhere on xilinx.com? (I couldn't find any right away) - If so, please add a link here. +/* Register offsets for the xps2 device */ +#define XPS2_SRST_OFFSET 0x /* Software Reset register */ +#define XPS2_STATUS_OFFSET0x0004 /* Status register */ +#define XPS2_RX_DATA_OFFSET 0x0008 /* Receive Data register */ +#define XPS2_TX_DATA_OFFSET 0x000C /* Transmit Data register */ +#define XPS2_GIER_OFFSET 0x002C /* Global Interrupt Enable reg */ +#define XPS2_IPISR_OFFSET 0x0030 /* Interrupt Status register */ +#define XPS2_IPIER_OFFSET 0x0038 /* Interrupt Enable register */ + +/* Reset Register Bit Definitions */ +#define XPS2_SRST_RESET 0x000A /* Software Reset */ + +/* Status Register Bit Positions */ +#define XPS2_STATUS_RX_FULL 0x0001 /* Receive Full */ +#define XPS2_STATUS_TX_FULL 0x0002 /* Transmit Full */ + +/* Bit definitions for ISR/IER registers. Both the registers have the same bit + * definitions and are only defined once. */ +#define XPS2_IPIXR_WDT_TOUT 0x0001 /* Watchdog Timeout Interrupt */ +#define XPS2_IPIXR_TX_NOACK 0x0002
initrd problem with device tree
I realize I'm asking below about u-boot, but I'm really trying to better understand how initrd should work with device trees. I have also posted a question to the u-boot user group. When I build the device tree blob into the kernel image and load the kernel image with my probe, it finds the initrd fine just using root=/dev/ram and with the kernel configured properly. With the same kernel configuration, when I run with u-boot, the only way for the kernel to find the initrd is to put linux,initrd-start and initrd-end in my device tree. I found these items in an old patch from David Gibson and I'm not sure if or when they should be used. I also notice in booting-without-of.txt, off_mem_rsvmap, but it's not clear if and how I should be using it to help the problem. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [V2] powerpc: Xilinx: add dts file for ML507 board
Thanks for the comments David.
-Original Message-
From: David Gibson [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2008 9:17 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [V2] powerpc: Xilinx: add dts file for ML507
board
On Mon, Jul 07, 2008 at 11:04:59AM -0700, John Linn wrote:
This new file adds support for the ML507 board which
has a Virtex 5 FXT FPGA with a 440.
Signed-off-by: John Linn [EMAIL PROTECTED]
---
V2
Converted to dts-v1 format.
Changed to match a newer reference design.
arch/powerpc/boot/dts/virtex440-ml507.dts | 296
+
1 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
diff --git a/arch/powerpc/boot/dts/virtex440-ml507.dts
b/arch/powerpc/boot/dts/virtex440-ml507.dts
new file mode 100644
index 000..d10a993
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml507.dts
@@ -0,0 +1,296 @@
+/*
+ * This file supports the Xilinx ML507 board with the 440
processor.
+ * A reference design for the FPGA is provided at
http://git.xilinx.com.
+ *
+ * (C) Copyright 2008 Xilinx, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
License
+ * version 2. This program is licensed as is without any warranty
of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = xlnx,virtex440;
+ dcr-parent = ppc440_0;
+ model = testing;
+ DDR2_SDRAM: [EMAIL PROTECTED] {
+ device_type = memory;
+ reg = 0 0x1000 ;
+ } ;
+ chosen {
+ bootargs = console=ttyS0 ip=on root=/dev/ram;
Bootargs like this should not typically go in the dts file.
My understanding is the bootloader would also fill these in.
With the FGPA, a bootloader is not used many times so that's the
reason we have put it into the dts file.
+ linux,stdout-path = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
+ } ;
+ cpus {
+ #address-cells = 1;
+ #cpus = 1;
+ #size-cells = 0;
+ ppc440_0: [EMAIL PROTECTED] {
+ clock-frequency = ;
Presumably this is supposed to be filled in by the bootloader. But in
any case it shouldn't be a string.
I think this was my screw-up as it should have the same value as the
timebase.
Interesting, it's not being used for anything that stops the system from
working.
[snip]
+ DMA0: [EMAIL PROTECTED] {
+ compatible = xlnx,ll-dma-1.00.a;
+ dcr-reg = 0x80 0x11 ;
+ interrupt-parent = xps_intc_0;
+ interrupts = 9 2 0xa 2 ;
+ } ;
Putting devices under the cpu node is certainly... atypical. It's not
obviously wrong, for a dcr device like this, but we probably want a
little more discussion before establishing a convention like this.
We had this discussion somewhat in a earlier message, 6/23 adding
virtex5
Powerpc 440 support, and Stephen answered with the following which still
seems
applicable.
From Stephenn:
In Virtex 5 FX, the processor block (as represented in all the processor
design tools) is actually a processor block, plus a crossbar switch,
plus dma blocks. I think there's a tradeoff between modeling this
independently, or modeling it as an FPGA user sees it. From the
perspective of the FPGA user, this is the way the system looks (although
I agree that it's odd). What would be even better, is if the processor
block was modeled as a DTS I could write by hand, and to include it into
the generated DTS. (Another good use for grafting of device trees...)
--
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
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Please pull linux-2.6-virtex.git
I'll look at the dts file and converting it to v1 format, hopefully soon. Thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Josh Boyer Sent: Monday, July 07, 2008 6:17 AM To: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org Subject: Re: Please pull linux-2.6-virtex.git On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote: Hi Josh, Here are the bulk of the Xilinx 440 support patches. Please pull into your next branch. Thanks, g. The following changes since commit f3e909c2750eb20536bacacc867dc9047b70546a: Michael Neuling (1): powerpc: Update for VSX core file and ptrace are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27 snip John Linn (5): powerpc/virtex: add dts file for ML507 reference design This one still isn't a dts-v1 file. Any chance of that getting fixed in the next day or two? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Please pull linux-2.6-virtex.git
Where should I be looking to understand what's needed for dts-v1 format? I did a quick review of Doc*/powerpc/booting-wihtout-of.txt and didn't see it, but maybe I overlooked it. Thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of John Linn Sent: Monday, July 07, 2008 8:14 AM To: Josh Boyer; [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org Subject: RE: Please pull linux-2.6-virtex.git I'll look at the dts file and converting it to v1 format, hopefully soon. Thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Josh Boyer Sent: Monday, July 07, 2008 6:17 AM To: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org Subject: Re: Please pull linux-2.6-virtex.git On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote: Hi Josh, Here are the bulk of the Xilinx 440 support patches. Please pull into your next branch. Thanks, g. The following changes since commit f3e909c2750eb20536bacacc867dc9047b70546a: Michael Neuling (1): powerpc: Update for VSX core file and ptrace are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27 snip John Linn (5): powerpc/virtex: add dts file for ML507 reference design This one still isn't a dts-v1 file. Any chance of that getting fixed in the next day or two? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver
Added a new driver for Xilinx XPS PS2 IP. This driver is
a flat driver to better match the Linux driver pattern.
Signed-off-by: Sadanand [EMAIL PROTECTED]
Signed-off-by: John Linn [EMAIL PROTECTED]
---
V2
Updated the driver based on feedback from Dmitry, Peter, and Grant.
We believe Montavista copyright is still valid.
V3
Incorporated Dmitry and Grant's 2nd set of comments which were some
minor cleanup and removal of the mutex which was not needed.
drivers/input/serio/Kconfig |5 +
drivers/input/serio/Makefile |1 +
drivers/input/serio/xilinx_ps2.c | 384 ++
3 files changed, 390 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/serio/xilinx_ps2.c
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index ec4b661..0e62b39 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -190,4 +190,9 @@ config SERIO_RAW
To compile this driver as a module, choose M here: the
module will be called serio_raw.
+config SERIO_XILINX_XPS_PS2
+ tristate Xilinx XPS PS/2 Controller Support
+ help
+ This driver supports XPS PS/2 IP from Xilinx EDK.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 38b8868..9b6c813 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_SERIO_PCIPS2)+= pcips2.o
obj-$(CONFIG_SERIO_MACEPS2)+= maceps2.o
obj-$(CONFIG_SERIO_LIBPS2) += libps2.o
obj-$(CONFIG_SERIO_RAW)+= serio_raw.o
+obj-$(CONFIG_SERIO_XILINX_XPS_PS2) += xilinx_ps2.o
diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
new file mode 100644
index 000..e86f11b
--- /dev/null
+++ b/drivers/input/serio/xilinx_ps2.c
@@ -0,0 +1,384 @@
+/*
+ * Xilinx XPS PS/2 device driver
+ *
+ * (c) 2005 MontaVista Software, Inc.
+ * (c) 2008 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+
+#include linux/module.h
+#include linux/serio.h
+#include linux/interrupt.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/list.h
+#include linux/io.h
+
+#include linux/of_device.h
+#include linux/of_platform.h
+
+#define DRIVER_NAMExilinx_ps2
+
+/* Register offsets for the xps2 device */
+#define XPS2_SRST_OFFSET 0x /* Software Reset register */
+#define XPS2_STATUS_OFFSET 0x0004 /* Status register */
+#define XPS2_RX_DATA_OFFSET0x0008 /* Receive Data register */
+#define XPS2_TX_DATA_OFFSET0x000C /* Transmit Data register */
+#define XPS2_GIER_OFFSET 0x002C /* Global Interrupt Enable reg */
+#define XPS2_IPISR_OFFSET 0x0030 /* Interrupt Status register */
+#define XPS2_IPIER_OFFSET 0x0038 /* Interrupt Enable register */
+
+/* Reset Register Bit Definitions */
+#define XPS2_SRST_RESET0x000A /* Software Reset */
+
+/* Status Register Bit Positions */
+#define XPS2_STATUS_RX_FULL0x0001 /* Receive Full */
+#define XPS2_STATUS_TX_FULL0x0002 /* Transmit Full */
+
+/* Bit definitions for ISR/IER registers. Both the registers have the same bit
+ * definitions and are only defined once. */
+#define XPS2_IPIXR_WDT_TOUT0x0001 /* Watchdog Timeout Interrupt */
+#define XPS2_IPIXR_TX_NOACK0x0002 /* Transmit No ACK Interrupt */
+#define XPS2_IPIXR_TX_ACK 0x0004 /* Transmit ACK (Data) Interrupt */
+#define XPS2_IPIXR_RX_OVF 0x0008 /* Receive Overflow Interrupt */
+#define XPS2_IPIXR_RX_ERR 0x0010 /* Receive Error Interrupt */
+#define XPS2_IPIXR_RX_FULL 0x0020 /* Receive Data Interrupt */
+
+/* Mask for all the Transmit Interrupts */
+#define XPS2_IPIXR_TX_ALL (XPS2_IPIXR_TX_NOACK | XPS2_IPIXR_TX_ACK)
+
+/* Mask for all the Receive Interrupts */
+#define XPS2_IPIXR_RX_ALL (XPS2_IPIXR_RX_OVF | XPS2_IPIXR_RX_ERR | \
+ XPS2_IPIXR_RX_FULL)
+
+/* Mask for all the Interrupts */
+#define XPS2_IPIXR_ALL (XPS2_IPIXR_TX_ALL | XPS2_IPIXR_RX_ALL | \
+ XPS2_IPIXR_WDT_TOUT)
+
+/* Global Interrupt Enable mask */
+#define XPS2_GIER_GIE_MASK 0x8000
+
+struct xps2data {
+ int irq;
+ u32 phys_addr;
+ u32 remap_size;
+ spinlock_t lock;
+ u8 rxb; /* Rx buffer */
+ void __iomem *base_address; /* virt. address of control registers */
+ unsigned int dfl;
+ struct serio serio
[PATCH] [V2] powerpc: Xilinx: add dts file for ML507 board
This new file adds support for the ML507 board which
has a Virtex 5 FXT FPGA with a 440.
Signed-off-by: John Linn [EMAIL PROTECTED]
---
V2
Converted to dts-v1 format.
Changed to match a newer reference design.
arch/powerpc/boot/dts/virtex440-ml507.dts | 296 +
1 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
diff --git a/arch/powerpc/boot/dts/virtex440-ml507.dts
b/arch/powerpc/boot/dts/virtex440-ml507.dts
new file mode 100644
index 000..d10a993
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml507.dts
@@ -0,0 +1,296 @@
+/*
+ * This file supports the Xilinx ML507 board with the 440 processor.
+ * A reference design for the FPGA is provided at http://git.xilinx.com.
+ *
+ * (C) Copyright 2008 Xilinx, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = xlnx,virtex440;
+ dcr-parent = ppc440_0;
+ model = testing;
+ DDR2_SDRAM: [EMAIL PROTECTED] {
+ device_type = memory;
+ reg = 0 0x1000 ;
+ } ;
+ chosen {
+ bootargs = console=ttyS0 ip=on root=/dev/ram;
+ linux,stdout-path = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
+ } ;
+ cpus {
+ #address-cells = 1;
+ #cpus = 1;
+ #size-cells = 0;
+ ppc440_0: [EMAIL PROTECTED] {
+ clock-frequency = ;
+ compatible = PowerPC,440, ibm,ppc440;
+ d-cache-line-size = 0x20;
+ d-cache-size = 0x8000;
+ dcr-access-method = native;
+ dcr-controller ;
+ device_type = cpu;
+ i-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ model = PowerPC,440;
+ reg = 0;
+ timebase-frequency = 0x17d78400;
+ xlnx,apu-control = 1;
+ xlnx,apu-udi-0 = 0;
+ xlnx,apu-udi-1 = 0;
+ xlnx,apu-udi-10 = 0;
+ xlnx,apu-udi-11 = 0;
+ xlnx,apu-udi-12 = 0;
+ xlnx,apu-udi-13 = 0;
+ xlnx,apu-udi-14 = 0;
+ xlnx,apu-udi-15 = 0;
+ xlnx,apu-udi-2 = 0;
+ xlnx,apu-udi-3 = 0;
+ xlnx,apu-udi-4 = 0;
+ xlnx,apu-udi-5 = 0;
+ xlnx,apu-udi-6 = 0;
+ xlnx,apu-udi-7 = 0;
+ xlnx,apu-udi-8 = 0;
+ xlnx,apu-udi-9 = 0;
+ xlnx,dcr-autolock-enable = 1;
+ xlnx,dcu-rd-ld-cache-plb-prio = 0;
+ xlnx,dcu-rd-noncache-plb-prio = 0;
+ xlnx,dcu-rd-touch-plb-prio = 0;
+ xlnx,dcu-rd-urgent-plb-prio = 0;
+ xlnx,dcu-wr-flush-plb-prio = 0;
+ xlnx,dcu-wr-store-plb-prio = 0;
+ xlnx,dcu-wr-urgent-plb-prio = 0;
+ xlnx,dma0-control = 0;
+ xlnx,dma0-plb-prio = 0;
+ xlnx,dma0-rxchannelctrl = 0x101;
+ xlnx,dma0-rxirqtimer = 0x3ff;
+ xlnx,dma0-txchannelctrl = 0x101;
+ xlnx,dma0-txirqtimer = 0x3ff;
+ xlnx,dma1-control = 0;
+ xlnx,dma1-plb-prio = 0;
+ xlnx,dma1-rxchannelctrl = 0x101;
+ xlnx,dma1-rxirqtimer = 0x3ff;
+ xlnx,dma1-txchannelctrl = 0x101;
+ xlnx,dma1-txirqtimer = 0x3ff;
+ xlnx,dma2-control = 0;
+ xlnx,dma2-plb-prio = 0;
+ xlnx,dma2-rxchannelctrl = 0x101;
+ xlnx,dma2-rxirqtimer = 0x3ff;
+ xlnx,dma2-txchannelctrl = 0x101;
+ xlnx,dma2-txirqtimer = 0x3ff;
+ xlnx,dma3-control = 0;
+ xlnx,dma3-plb-prio = 0;
+ xlnx,dma3-rxchannelctrl = 0x101;
+ xlnx,dma3-rxirqtimer = 0x3ff;
+ xlnx,dma3-txchannelctrl = 0x101;
+ xlnx,dma3-txirqtimer = 0x3ff;
+ xlnx,endian-reset = 0;
+ xlnx,generate-plb-timespecs = 1;
+ xlnx,icu-rd-fetch-plb-prio = 0;
+ xlnx,icu-rd-spec-plb-prio = 0;
+ xlnx,icu-rd-touch-plb-prio = 0
RE: [PATCH] [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver
Thanks Dmitry, appreciate the help. Powerpc dependencies in the Kconfig sound right. Sorry for not thinking that thru well across all architectures. Do you want me to spin the patch again? -- John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Dmitry Torokhov Sent: Monday, July 07, 2008 12:20 PM To: John Linn Cc: Sadanand Mutyala; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: [PATCH] [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver On Mon, Jul 07, 2008 at 08:38:45AM -0700, John Linn wrote: Added a new driver for Xilinx XPS PS2 IP. This driver is a flat driver to better match the Linux driver pattern. Signed-off-by: Sadanand [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] Looks good and I am ready to apply with the exception that compile errors out when i try to build on x86 (asm/prom.h is missing). Do we need some Kconfig dependencies added? -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Xilinx: PS2: Update Kconfig for new XPS PS2 driver
This patch is an incremental patch for the patch titled: [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver. This patch adds powerpc as a dependency for the driver. Signed-off-by: Sadanand [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] --- drivers/input/serio/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index 0e62b39..683f495 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -192,7 +192,9 @@ config SERIO_RAW config SERIO_XILINX_XPS_PS2 tristate Xilinx XPS PS/2 Controller Support + depends on PPC help - This driver supports XPS PS/2 IP from Xilinx EDK. + This driver supports XPS PS/2 IP from the Xilinx EDK on the + PowerPC platform. endif -- 1.5.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: Xilinx: add 440 platform support
XILINX_VIRTEX_5_FXT is the FPGA architecture, which has a 440 and can be on a number of different boards. Thanks, John -Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 7:15 AM To: John Linn Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; John Linn Subject: Re: [PATCH] powerpc: Xilinx: add 440 platform support On Tue, 1 Jul 2008 15:48:26 -0700 John Linn [EMAIL PROTECTED] wrote: Support for the Xilinx Virtex5 FXT 440 is being added. Signed-off-by: John Linn [EMAIL PROTECTED] --- arch/powerpc/platforms/44x/Kconfig | 25 ++ arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/virtex.c | 60 +++ 3 files changed, 86 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/platforms/44x/virtex.c diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index 6abe913..84eb847 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -102,6 +102,22 @@ config YOSEMITE # help #This option enables support for the IBM PPC440GX evaluation board. +config XILINX_VIRTEX440_GENERIC_BOARD + bool Generic Xilinx Virtex 440 board + depends on 44x + default n + select XILINX_VIRTEX_5_FXT If this is for generic Virtex 440 board support, why is it selecting a specific Virtex 5 board? Or am I confused as to what XILINX_VIRTEX_5_FXT is? josh This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: Xilinx: add 440 platform support
Not a problem, I'll add it and respin the patch. -Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 7:21 AM To: John Linn Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: [PATCH] powerpc: Xilinx: add 440 platform support On Thu, 3 Jul 2008 07:20:45 -0600 John Linn [EMAIL PROTECTED] wrote: XILINX_VIRTEX_5_FXT is the FPGA architecture, which has a 440 and can be on a number of different boards. Could you add that as some help text under the config option for 5_FXT? That way you don't have to answer that question over and over from stupid people like me :) josh This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V3] powerpc: Xilinx: add 440 platform support
Support for the Xilinx Virtex5 FXT 440 is being
added.
Signed-off-by: John Linn [EMAIL PROTECTED]
---
V1 V2
bad mailing list address, never got to mailing list
V3
added more help to Kconfig, requested from Josh
arch/powerpc/platforms/44x/Kconfig | 26 +++
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/virtex.c | 60 +++
3 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/virtex.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 6abe913..429ae34 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -102,6 +102,22 @@ config YOSEMITE
# help
#This option enables support for the IBM PPC440GX evaluation board.
+config XILINX_VIRTEX440_GENERIC_BOARD
+ bool Generic Xilinx Virtex 440 board
+ depends on 44x
+ default n
+ select XILINX_VIRTEX_5_FXT
+ help
+ This option enables generic support for Xilinx Virtex based boards
+ that use a 440 based processor in the Virtex 5 FXT FPGA architecture.
+
+ The generic virtex board support matches any device tree which
+ specifies 'xlnx,virtex440' in its compatible field. This includes
+ the Xilinx ML5xx reference designs using the powerpc core.
+
+ Most Virtex 5 designs should use this unless it needs to do some
+ special configuration at board probe time.
+
# 44x specific CPU modules, selected based on the board above.
config 440EP
bool
@@ -152,3 +168,13 @@ config 460EX
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
+
+# Xilinx specific config options.
+config XILINX_VIRTEX
+ bool
+
+# Xilinx Virtex 5 FXT FPGA architecture, selected by a Xilinx board above
+config XILINX_VIRTEX_5_FXT
+ bool
+ select XILINX_VIRTEX
+
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 774165f..dbfae1d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_CANYONLANDS) += canyonlands.o
+obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/virtex.c
b/arch/powerpc/platforms/44x/virtex.c
new file mode 100644
index 000..68637fa
--- /dev/null
+++ b/arch/powerpc/platforms/44x/virtex.c
@@ -0,0 +1,60 @@
+/*
+ * Xilinx Virtex 5FXT based board support, derived from
+ * the Xilinx Virtex (IIpro 4FX) based board support
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ * Copyright 2008 Xilinx, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/init.h
+#include linux/of_platform.h
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/time.h
+#include asm/xilinx_intc.h
+#include asm/reg.h
+#include asm/ppc4xx.h
+#include 44x.h
+
+static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = simple-bus, },
+ { .compatible = xlnx,plb-v46-1.00.a, },
+ { .compatible = xlnx,plb-v46-1.02.a, },
+ { .compatible = xlnx,plb-v34-1.01.a, },
+ { .compatible = xlnx,plb-v34-1.02.a, },
+ { .compatible = xlnx,opb-v20-1.10.c, },
+ { .compatible = xlnx,dcr-v29-1.00.a, },
+ { .compatible = xlnx,compound, },
+ {}
+};
+
+static int __init virtex_device_probe(void)
+{
+ of_platform_bus_probe(NULL, xilinx_of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(virtex, virtex_device_probe);
+
+static int __init virtex_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, xlnx,virtex440))
+ return 0;
+
+ return 1;
+}
+
+define_machine(virtex) {
+ .name = Xilinx Virtex440,
+ .probe = virtex_probe,
+ .init_IRQ = xilinx_intc_init_tree,
+ .get_irq= xilinx_intc_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+ .restart= ppc4xx_reset_system,
+};
--
1.5.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
