lkml.org 
[lkml]   [2011]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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
>
>




\
 
 \ /
  Last update: 2011-10-11 03:43    [W:1.033 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site