Re: PCIe can not rescan for new PCIe device ( FPGA board )

[Kenji Kaneshige]

(2011/10/08 1:36), Bjorn Helgaas wrote:
> On Fri, Oct 7, 2011 at 10:22 AM, Abdelghani Ouchabane
> <abdelghani@xxxxxxxxx>  wrote:
> > Bjorn Helgaas wrote:
> > > [added cc: linux-pci@xxxxxxxxxxxxxxx]
> > >
> > > On Fri, Oct 7, 2011 at 1:16 AM, Abdelghani Ouchabane
> > > <abdelghani@xxxxxxxxx>  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?
> >
> > Thanks Bjorn,
> >
> > Yes, I have them :
> >
> > ****************************************************************************************************
> > lsmod :
> >
> > pciehp                 20282  0
> > cgosdrv                17632  0
> > ****************************************************************************************************
> > /etc/modprobe.d/pciehp.conf
> > alias pci:v00001234d00000002sv00001234sd00000001bc11sc80i00 pciehp
> > options pciehp pciehp_force=1 pciehp_debug=1
> > ****************************************************************************************************
> >
> > After I plug my board in,  I executed  echo 1>  /sys/bus/pci/rescan

Can you try echo 1 > /sys/bus/pci/slots/XXX/power?
(XXX: slot number)

> It seems like a pciehp bug that you have to rescan explicitly.  But
> I'm not a pciehp expert and I haven't looked at the code.

The pciehp automatically scans the bus on presence changed event
(e.g. board is pluged in) if the hot-plug controller supports
surprise removal. Otherwise, you need to power on slot explicitly
by "echo 1 > /sys/bus/pci/slots/XXX/power". So one possibility is
that your controller doesn't support surprise removal. We can
check it by looking at the pciehp's debug output. Can you send
whole dmesg output?

Regards,
Kenji Kaneshige


> > > > * But our software returns : 0xFFFFFFFF
>
> This is reading from your device's memory region.  It looks like the
> device is configured correctly (BAR values are reasonable and memory
> decoding is enabled) and I assume the bridges leading to it are
> configured correctly (if you posted the complete dmesg log we could
> tell for sure).  After that point, Linux is out of the way and it's
> just a question of whether your device responds correctly to the
> memory access.
>
> Are you sure the device is supposed to return something other than
> 0xFFFFFFFF?  If it's memory, can you write to it and read the new
> value back?  Can you use a PCIe analyzer and see if the device is
> responding correctly on the bus?
>
> Other than the possible pciehp rescan problem, this just looks like a
> problem with your FPGA.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/