(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-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
