Messages in this thread | | | Date | Tue, 11 Oct 2011 10:39:41 +0900 | From | Kenji Kaneshige <> | Subject | Re: PCIe can not rescan for new PCIe device ( FPGA board ) |
| |
(2011/10/08 1:36), Bjorn Helgaas wrote: > On Fri, Oct 7, 2011 at 10:22 AM, Abdelghani Ouchabane > <abdelghani@ezono.com> wrote: >> Bjorn Helgaas wrote: >>> >>> [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? >>> >> >> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
| |