mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Abdelghani Ouchabane <abdelghani@ezono.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: PCIe can not rescan for new PCIe device ( FPGA board )
Date: Tue, 11 Oct 2011 10:39:41 +0900	[thread overview]
Message-ID: <4E939E5D.3010208@jp.fujitsu.com> (raw)
In-Reply-To: <CAErSpo6Lo2bXw=yjscQ6zzRMnpMZ-cUzbBxN3dDS1D3M67sQ8g@mail.gmail.com>

(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
>
>



  reply	other threads:[~2011-10-11  1:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-07  7:16 Abdelghani Ouchabane
2011-10-07 15:37 ` Bjorn Helgaas
2011-10-07 16:22   ` Abdelghani Ouchabane
2011-10-07 16:36     ` Bjorn Helgaas
2011-10-11  1:39       ` Kenji Kaneshige [this message]
2011-10-11  8:11         ` Abdelghani Ouchabane
2011-10-12  6:36           ` Kenji Kaneshige
2011-10-12  8:35             ` Abdelghani Ouchabane
2011-10-13 12:50               ` Kenji Kaneshige
2011-10-14  9:40                 ` Abdelghani Ouchabane
2011-10-24  5:00                   ` Kenji Kaneshige
2011-10-24  9:20                     ` Abdelghani Ouchabane
2011-10-11  8:10       ` Abdelghani Ouchabane
2011-10-11 15:22         ` Bjorn Helgaas
     [not found]           ` <4E954251.5020801@ezono.com>
2011-10-12  8:03             ` Abdelghani Ouchabane
2011-10-12 15:58               ` Bjorn Helgaas
2011-10-14  9:27                 ` Abdelghani Ouchabane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E939E5D.3010208@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=abdelghani@ezono.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome