lkml.org 
[lkml]   [2011]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: PCIe can not rescan for new PCIe device ( FPGA board )
[added cc: linux-pci@vger.kernel.org]

On Fri, Oct 7, 2011 at 1:16 AM, Abdelghani Ouchabane
<abdelghani@ezono.com> wrote:
> Hallo,
>
>  We are developing a FPGA board connected to a Fedora 15 PC host over PCIe.
> Right now, in the implementation and debug phase, I often need to power off
> and
> power on the device or try different boards. This causes a problem with the
> Fedora 15 running on the AMD PC.
>
> Typically the PC is booted when I need to insert the device under test. As
> expected, the Linux doesn't find the device and the software app cannot talk
> to it.
>
> * If I do "lspci -v" then it does not list our device.

Do you have pciehp enabled and loaded? I would think a PCIe hot-add
should automatically rescan the bus. Does dmesg say anything when you
do the hot-add?

> * Then I execute "echo 1 > /sys/bus/pci/rescan"
>
> * Now "lspci -v" lists our device.

That means config space accesses to your device seem to work fine.

> * But our software returns : 0xFFFFFFFF

Your device is on bus 02. Did you confirm that there are host bridge
and P2P bridge apertures containing the BARs, e.g,. the [mem
0x40241000-0x40241fff] region? The dmesg log should show all this
information.

Bjorn

> ************************************************************************************************************************************************************
> [root@localhost ~]# show_regs
> resource file = /sys/bus/pci/devices/0000:02:00.0/resource
> base address  = 0x40241000
>   0x40241000    0x00000000    0xFFFFFFFF    0xFFFFFFFF
>   0x40241008    0x00000008    0xFFFFFFFF    0xFFFFFFFF
>   0x40241010    0x00000010    0xFFFFFFFF    0xFFFFFFFF
>   0x40241018    0x00000018    0xFFFFFFFF    0xFFFFFFFF
>   0x40241020    0x00000020    0xFFFFFFFF    0xFFFFFFFF
>   0x40241028    0x00000028    0xFFFFFFFF    0xFFFFFFFF
>   0x40241030    0x00000030    0xFFFFFFFF    0xFFFFFFFF
>   0x40241038    0x00000038    0xFFFFFFFF    0xFFFFFFFF
>   0x40241040    0x00000040    0xFFFFFFFF    0xFFFFFFFF
>   0x40241048    0x00000048    0xFFFFFFFF    0xFFFFFFFF
>   0x40241050    0x00000050    0xFFFFFFFF    0xFFFFFFFF
>   0x40241058    0x00000058    0xFFFFFFFF    0xFFFFFFFF
>
>
> ************************************************************************************************************************************************************
> lspci -vvv
>
> 02:00.0 Signal processing controller: eZono AG eZono Malta - 32 channels
> ultrasound front end (rev 01)
>        Subsystem: eZono AG Device 0001
>        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Interrupt: pin A routed to IRQ 7
>        Region 0: Memory at 40240000 (64-bit, prefetchable) [size=4K]
>        Region 2: Memory at 40200000 (64-bit, prefetchable) [size=256K]
>        Region 4: Memory at 40241000 (64-bit, prefetchable) [size=4K]
>        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>                Address: 0000000000000000  Data: 0000
>        Capabilities: [78] Power Management version 3
>                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>        Capabilities: [80] Express (v1) Endpoint, MSI 00
>                DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s
> <64ns, L1 <1us
>                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
>                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                        MaxPayload 128 bytes, MaxReadReq 512 bytes
>                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend-
>                LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s, Latency
> L0 <1us, L1 <1us
>                        ClockPM- Surprise- LLActRep- BwNot-
>                LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain-
> CommClk-
>                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk-
> DLActive- BWMgmt- ABWMgmt-
>
>
> ************************************************************************************************************************************************************
> lspci -xxx
>
> 02:00.0 Signal processing controller: eZono AG eZono Malta - 32 channels
> ultrasound front end (rev 01)
> 00: 34 12 02 00 02 00 10 00 01 00 80 11 00 00 00 00
> 10: 0c 00 24 40 00 00 00 00 0c 00 20 40 00 00 00 00
> 20: 0c 10 24 40 00 00 00 00 00 00 00 00 34 12 01 00
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 00 01 00 00
> 40: 00 00 00 00 70 61 62 01 00 00 00 00 00 00 00 00
> 50: 05 78 80 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 01 80 03 00 00 00 00 00
> 80: 10 00 01 00 04 80 2c 01 10 28 00 00 11 44 00 01
> 90: 01 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> ************************************************************************************************************************************************************
>
> It looks that 'rescan' is not enough to handle cases like this? Or, is there
> a
> way to "insert" the FPGAs later after the kernel boots up?
>
>
> Many thanks in advance, Ghani
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-10-07 17:41    [W:0.158 / U:4.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site