<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I may have come across a similar problem, but I’ve never
worked card-to-card without at least one switch in the way.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The problems I have encountered have been hang-ups during memory-mapped
maintenance reads to devices that the switch reports as “up”.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A workaround for the hang-up is to use a DMA transfer that
bypasses the ATMU to perform a maintenance read (not all, just the first, a
test read of a new discovery). If the DMA fails, as it does in those unusual
circumstances, it will report a bus transfer error - but it will not hang up. You
can recover, and avoid or re-try the connection later.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A real “fix” for your problem may be to ensure that
both of your RapidIO interfaces are programmed to accept all incoming
transactions (see “Accept All Configuration Register (AACR)” in
Freescale reference manual). But no guarantees with that - it just seemed to
clear up problems on my own rig.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> linuxppc-dev-bounces+tanderson=curtisswright.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tanderson=curtisswright.com@lists.ozlabs.org] <b>On
Behalf Of </b>Bastiaan Nijkamp<br>
<b>Sent:</b> Tuesday, October 05, 2010 7:28 AM<br>
<b>To:</b> John Traill<br>
<b>Cc:</b> Bounine, Alexandre; linuxppc-dev@lists.ozlabs.org<br>
<b>Subject:</b> Re: Serial RapidIO Maintaintance read causes lock up<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>Hi John,<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>1. Yes, they are both running the exact same kernel and both
are configured in the same way. With the exception that one is set as host and
the other as a agent.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>2. Accept All is set for both boards. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>3. As i understand, the agent cannot send anything before it
is enumerated, so it would be safe to first reset the agent and
right after that the host. In either case, thats the way i am using. The
full kernel log until the discovery times out after 30 seconds is shown below:<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Using SBC8548 machine description<br>
Memory CAM mapping: 256 Mb, residual: 0Mb<br>
Linux version 2.6.35.6 (<a href="mailto:dl704@lxws006">dl704@lxws006</a>) (gcc
version 4.4.1 (Wind River Linux Sour<br>
cery G++ 4.4-250) ) #3 Tue Oct 5 13:24:45 CEST 2010<br>
bootconsole [udbg0] enabled<br>
setup_arch: bootmem<br>
sbc8548_setup_arch()<br>
arch: exit<br>
Zone PFN ranges:<br>
DMA 0x00000000 -> 0x00010000<br>
Normal empty<br>
Movable zone start PFN for each node<br>
early_node_map[1] active PFN ranges<br>
0: 0x00000000 -> 0x00010000<br>
MMU: Allocated 1088 bytes of context maps for 255 contexts<br>
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024<br>
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.100.21:/thales/target/rfs/<br>
sbc8548_wrlinux4 ip=192.168.100.151:192.168.100.21:192.168.100.21:255.255.255.0:<br>
sbc8548_1:eth0:off console=ttyS0,115200<br>
PID hash table entries: 1024 (order: 0, 4096 bytes)<br>
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)<br>
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)<br>
Memory: 256996k/262144k available (2644k kernel code, 5148k reserved, 108k
data,<br>
77k bss, 136k init)<br>
Kernel virtual memory layout:<br>
* 0xfffdf000..0xfffff000 : fixmap<br>
* 0xfdffd000..0xfe000000 : early ioremap<br>
* 0xd1000000..0xfdffd000 : vmalloc & ioremap<br>
Hierarchical RCU implementation.<br>
RCU-based detection of stalled CPUs is disabled.<br>
Verbose stalled-CPUs detection is disabled.<br>
NR_IRQS:512 nr_irqs:512<br>
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max
1 CPUs<br>
mpic: ISU size: 80, shift: 7, mask: 7f<br>
mpic: Initializing for 80 sources<br>
clocksource: timebase mult[50cede6] shift[22] registered<br>
pid_max: default: 32768 minimum: 301<br>
Mount-cache hash table entries: 512<br>
NET: Registered protocol family 16<br>
<br>
PCI: Probing PCI hardware<br>
bio: create slab <bio-0> at 0<br>
vgaarb: loaded<br>
Switching to clocksource timebase<br>
NET: Registered protocol family 2<br>
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)<br>
TCP established hash table entries: 8192 (order: 4, 65536 bytes)<br>
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)<br>
TCP: Hash tables configured (established 8192 bind 8192)<br>
TCP reno registered<br>
UDP hash table entries: 256 (order: 0, 4096 bytes)<br>
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)<br>
NET: Registered protocol family 1<br>
RPC: Registered udp transport module.<br>
RPC: Registered tcp transport module.<br>
RPC: Registered tcp NFSv4.1 backchannel transport module.<br>
Setting up RapidIO peer-to-peer network /soc8548@e0000000/rapidio@c0000<br>
fsl-of-rio e00c0000.rapidio: Of-device full name
/soc8548@e0000000/rapidio@c0000<br>
fsl-of-rio e00c0000.rapidio: Regs: [mem 0xe00c0000-0xe00dffff]<br>
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
0x0000000020000000.<br>
fsl-of-rio e00c0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54<br>
fsl-of-rio e00c0000.rapidio: DeviceID is 0xffffffff<br>
fsl-of-rio e00c0000.rapidio: Configured as AGENT<br>
fsl-of-rio e00c0000.rapidio: Overriding RIO_PORT setting to single lane 0<br>
fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial<br>
fsl-of-rio e00c0000.rapidio: Hardware port width: 4<br>
fsl-of-rio e00c0000.rapidio: Training connection status: Single-lane 0<br>
fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256<br>
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, RIO Maintainance
Window Size 0x400000,New Main Start: 0xd1080000<br>
RIO: discover master port 0, RIO0 mport<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>A interesting thing that i found out is that when the agent
is reset while the host is locked up (eg. it cannot be stopped nor can i read
the registers and memory trough a JTAG Interface), the host comes back online
and just continues booting linux with a RapidIO error. See the log below.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Setting up RapidIO peer-to-peer network
/soc8548@e0000000/rapidio@c0000<br>
fsl-of-rio e00c0000.rapidio: Of-device full name /soc8548@e0000000/rapidio@c0000<br>
fsl-of-rio e00c0000.rapidio: Regs: [mem 0xe00c0000-0xe00dffff]<br>
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
0x0000000020000000.<br>
fsl-of-rio e00c0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54<br>
fsl-of-rio e00c0000.rapidio: DeviceID is 0x0<br>
fsl-of-rio e00c0000.rapidio: Configured as HOST<br>
fsl-of-rio e00c0000.rapidio: Overriding RIO_PORT setting to single lane 0<br>
fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial<br>
fsl-of-rio e00c0000.rapidio: Hardware port width: 4<br>
fsl-of-rio e00c0000.rapidio: Training connection status: Single-lane 0<br>
fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256<br>
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, RIO Maintainance
Window Size 0x400000,New Main Start: 0xd1080000<br>
RIO: enumerate master port 0, RIO0 mport<br>
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4<br>
fsl_rio_config_read: Passed IS_ALIGNED.<br>
fsl_rio_config_read: Passed 'out_be32_1'<br>
fsl_rio_config_read: Passed 'out_be32_2'<br>
fsl_rio_config_read: len is 4<br>
fsl_rio_config_read: triggering '__fsl_read_rio_config'<br>
fsl_rio_config_read: going to request to read data at d1080068<br>
RIO: cfg_read error -14 for ff:0:68<br>
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4<br>
fsl_rio_config_read: Passed IS_ALIGNED.<br>
fsl_rio_config_read: Passed 'out_be32_1'<br>
fsl_rio_config_read: Passed 'out_be32_2'<br>
fsl_rio_config_read: len is 4<br>
fsl_rio_config_read: triggering '__fsl_read_rio_config'<br>
fsl_rio_config_read: going to request to read data at d1080068<br>
RIO: cfg_read error -14 for ff:0:68<br>
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4<br>
fsl_rio_config_read: Passed IS_ALIGNED.<br>
fsl_rio_config_read: Passed 'out_be32_1'<br>
fsl_rio_config_read: Passed 'out_be32_2'<br>
fsl_rio_config_read: len is 4<br>
fsl_rio_config_read: triggering '__fsl_read_rio_config'<br>
fsl_rio_config_read: going to request to read data at d1080068<br>
RIO: cfg_read error -14 for ff:0:68<br>
RIO: master port 0 device has lost enumeration to a remote host<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><br>
Regards,<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Bastiaan<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>2010/10/5 John Traill <<a
href="mailto:john.traill@freescale.com">john.traill@freescale.com</a>><o:p></o:p></p>
<p class=MsoNormal>Bastiaan,<br>
<br>
A few things to check.<br>
<br>
1. Is the target board also set up for small common transport system size ie
256.<br>
<br>
2. Make sure the target has "Accept All" set - in fsl_rio.c look for<o:p></o:p></p>
<p class=MsoNormal> /* Set to receive any dist ID for
serial RapidIO controller. */<br>
if (port->phy_type == RIO_PHY_SERIAL)<br>
out_be32((priv->regs_win + RIO_ISR_AACR), RIO_ISR_AACR_AA);<o:p></o:p></p>
<p class=MsoNormal><br>
3. How do you synchronise reset between both systems ? Both need to be reset to
insure the inbound/outbound ackid's remain in sync. If you only reset one then
you have the potential for the ackid's to get out of sync. Also what is the
kernel log on the agent system ?<br>
<br>
Cheers. <o:p></o:p></p>
<div>
<div>
<p class=MsoNormal><br>
<br>
<br>
On 05/10/10 09:56, Bastiaan Nijkamp wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p class=MsoNormal><br>
Hi Alex,<br>
<br>
Thanks for your advice. We are trying to make a board-to-board<br>
connection without any additional hardware (eg. a switch). The boards<br>
use a 50-pin, right-angle MEC8-125-02-L-D-RA1 connector from SAMTEC and<br>
are connected trough a EEDP-016-12.00-RA1-RA2-2 cross cable from SAMTEC.<br>
I hope this information is sufficient since there is not much one can<br>
find about it on Google. In addition, you can see a picture of the board<br>
including the connector in the datasheet located at<br>
<a
href="http://www.windriver.com/products/product-notes/SBC8548E-product-note.pdf"
target="_blank">http://www.windriver.com/products/product-notes/SBC8548E-product-note.pdf</a>.<br>
It is the connector on the left side of the PCI-EX slot.<br>
<br>
We have tried your suggestion but the situation does not change other<br>
than the lane-mode being set to single lane 0, it still locks up when<br>
trying to generate a maintenance transaction. I still think it is memory<br>
related since the lock up occurs when accessing the maintenance window.<br>
Although all memory related settings seems to be alright.<br>
<br>
The kernel output is as follows:<br>
<br>
Setting up RapidIO peer-to-peer network /soc8548@e0000000/rapidio@c0000<br>
fsl-of-rio e00c0000.rapidio: Of-device full name<br>
/soc8548@e0000000/rapidio@c0000<br>
fsl-of-rio e00c0000.rapidio: Regs: [mem 0xe00c0000-0xe00dffff]<br>
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size<br>
0x0000000010000000.<br>
fsl-of-rio e00c0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54<br>
fsl-of-rio e00c0000.rapidio: DeviceID is 0x0<br>
fsl-of-rio e00c0000.rapidio: Configured as HOST<br>
fsl-of-rio e00c0000.rapidio: Overriding RIO_PORT setting to single lane 0<br>
fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial<br>
fsl-of-rio e00c0000.rapidio: Hardware port width: 4<br>
fsl-of-rio e00c0000.rapidio: Training connection status: Single-lane 0<br>
fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256<br>
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, RIO<br>
Maintainance Window Size 0x400000,New Main Start: 0xd1080000<br>
RIO: enumerate master port 0, RIO0 mport<br>
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4<br>
fsl_rio_config_read: Passed IS_ALIGNED.<br>
fsl_rio_config_read: Passed 'out_be32_1'<br>
fsl_rio_config_read: Passed 'out_be32_2'<br>
fsl_rio_config_read: len is 4<br>
fsl_rio_config_read: triggering '__fsl_read_rio_config'<br>
fsl_rio_config_read: going to request to read data at d108006<br>
<br>
Regards,<br>
Bastiaan<br>
<br>
2010/10/4 Bounine, Alexandre <<a href="mailto:Alexandre.Bounine@idt.com"
target="_blank">Alexandre.Bounine@idt.com</a><o:p></o:p></p>
</div>
</div>
<p class=MsoNormal><mailto:<a href="mailto:Alexandre.Bounine@idt.com"
target="_blank">Alexandre.Bounine@idt.com</a>>> <o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
Hi Bastiaan,<br>
<br>
Are you trying board-to-board connection?<br>
I am not familiar with WRS SBC8548 board - which type of connector
they<br>
use for SRIO?<br>
<br>
Assuming that all configuration is correct,<br>
I would recommend first to try setting up x1 link mode at the
lowest<br>
link speed.<br>
The x4 mode may present challenges in some cases.<br>
<br>
For quick test you may just add port width override into fsl_rio.c<br>
like shown below (ugly but sometimes it helps ;) ):<br>
<br>
@@ -1461,10 +1461,16 @@ int fsl_rio_setup(struct platform_device
*dev)<br>
rio_register_mport(port);<br>
<br>
priv->regs_win =
ioremap(regs.start, regs.end - regs.start + 1);<br>
rio_regs_win = priv->regs_win;<br>
<br>
+dev_info(&dev->dev, "Overriding RIO_PORT setting to
single lane 0\n");<br>
+out_be32(priv->regs_win + 0x15C, in_be32(priv->regs_win +
0x15C) |<br>
0x800000);<br>
+out_be32(priv->regs_win + 0x15C, in_be32(priv->regs_win +
0x15C) |<br>
0x2000000);<br>
+out_be32(priv->regs_win + 0x15C, in_be32(priv->regs_win +
0x15C) &<br>
~0x800000);<br>
+msleep(100);<br>
+<br>
/* Probe the master port phy type */<br>
ccsr = in_be32(priv->regs_win +
RIO_CCSR);<br>
port->phy_type = (ccsr & 1) ?
RIO_PHY_SERIAL : RIO_PHY_PARALLEL;<br>
dev_info(&dev->dev,
"RapidIO PHY type: %s\n",<br>
(port->phy_type == RIO_PHY_PARALLEL) ?<br>
"parallel" :<br>
<br>
<br>
Let me know what happens.<br>
Please keep me in the CC: list next time when posting RapidIO
questions<br>
to the linuxppc-dev or kernel mailing lists.<br>
<br>
Regards,<br>
<br>
Alex.<br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
<p class=MsoNormal>_______________________________________________<br>
Linuxppc-dev mailing list<br>
<a href="mailto:Linuxppc-dev@lists.ozlabs.org" target="_blank">Linuxppc-dev@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_blank">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><o:p></o:p></p>
</blockquote>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
-- <br>
John Traill<br>
Systems Engineer<br>
Network and Computing Systems Group<br>
<br>
Freescale Semiconductor UK LTD<br>
Colvilles Road<br>
East Kilbride<br>
Glasgow G75 0TG, Scotland<br>
<br>
Tel: +44 (0) 1355 355494<br>
Fax: +44 (0) 1355 261790<br>
<br>
E-mail: <a href="mailto:john.traill@freescale.com" target="_blank">john.traill@freescale.com</a><br>
<br>
Registration Number: SC262720<br>
VAT Number: GB831329053<br>
<br>
[ ] General Business Use<br>
[ ] Freescale Internal Use Only<br>
[ ] Freescale Confidential Proprietary<o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
<BR>
_______________________________________________________________________<BR>
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this email and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.<BR>
</body>
</html>