linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: PCI IO resource question.
Date: Fri, 18 Mar 2016 14:12:51 -0400	[thread overview]
Message-ID: <56EC4523.9010304@ti.com> (raw)
In-Reply-To: <20160318152824.GA18864@localhost>

On 03/18/2016 11:28 AM, Bjorn Helgaas wrote:
> On Fri, Mar 18, 2016 at 11:09:27AM -0400, Murali Karicheri wrote:
>> On 03/18/2016 07:28 AM, Lorenzo Pieralisi wrote:
>>> On Thu, Mar 17, 2016 at 05:28:31PM -0400, Murali Karicheri wrote:
>>>
>>> [...]
>>>
>>>>> The only ways I see that PCI_PROBE_ONLY can be set on ARM are if you have
>>>>> "linux,pci-probe-only" in your DT or you boot with "pci=firmware".
>>>>>
>>>>> I expect you're in this path:
>>>>>
>>>>>   ahci_init_one
>>>>>     pcim_enable_device
>>>>>       pci_enable_device
>>>>>         pci_enable_device_flags(dev, IORESOURCE_MEM | IORESOURCE_IO)
>>>>>           # build "bars" mask
>>>>>           do_pci_enable_device(dev, bars)
>>>>>             pcibios_enable_device
>>>>>               if (pci_has_flag(PCI_PROBE_ONLY))
>>>>>                 return 0;
>>>>>               pci_enable_resources
>>>>>
>>>>> Can you add a little debug code like this to verify that we're in this
>>>>> path?
>>>>
>>>> Yes we are in the path.
>>>>
>>>>
>>>> [    1.557561] ahci_init_one
>>>> [    1.560214] ahci 0000:01:00.0: version 3.0
>>>> [    1.564302] pcim_enable_device
>>>> [    1.567349] pci_enable_device
>>>> [    1.570340] pci_enable_device_flags
>>>> [    1.573824] do_pci_enable_device
>>>> [    1.577042] pcibios_enable_device
>>>> [    1.580380] pci_enable_resources
>>>
>>> So resources are actually enabled (ie PCI_PROBE_ONLY is not set)
>>> and that makes sense otherwise you would not be able to use the
>>> MEM resources anyway (ie they would not be enabled).
>>>
>>> I suspect the PCI dev IO resources were reset in reset_resource() in
>>> assign_requested_resource_sorted(), hence the bar mask that is built
>>> in pci_enable_device_flags() does not contain the IO resources,
>>> it would be helpful if you can print the bar mask passed to
>>> pcibios_enable_device() (ie the mask parameter).
>>
>> Here it is
>>
>> [    1.556507] ahci_init_one
>> [    1.559124] ahci 0000:01:00.0: version 3.0
>> [    1.563246] pcim_enable_device
>> [    1.566294] pci_enable_device
>> [    1.569252] pci_enable_device_flags
>> [    1.572766] do_pci_enable_device
>> [    1.575985] pcibios_enable_device 60
>> [    1.579551] pci_enable_resources
>>
>> I know that some of our customers use PCIe SATA from u-boot and would
>> like to honor the assignment in Linux space.. I believe they use PCI_PROBE_ONLY
>> by setting the bootarg. So Keystone PCI should work in both cases.
> 
> We're only getting little pieces of the story here.  Can you apply the
> following patch and collect the entire dmesg log?  I want to see:
> 
>   - the root bus resources (which presumably include no I/O space)
>   - all the SATA resources during enumeration (which should include an
>     I/O BAR)
>   - the reset_resource() call that clears the I/O BAR flags
>   - all the SATA resources in pci_enable_resources() (the I/O BAR
>     should be cleared out)
>   - the PCI_COMMAND register values before and after
>     pci_enable_resources()
> 
> Bjorn
> 
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 55641a3..83e8d42 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -211,6 +211,7 @@ static void __dev_sort_resources(struct pci_dev *dev,
>  
>  static inline void reset_resource(struct resource *res)
>  {
> +	printk("%s: %pR\n", __func__, res);
>  	res->start = 0;
>  	res->end = 0;
>  	res->flags = 0;
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 66c4d8f..c2c45f9 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -364,11 +364,14 @@ int pci_enable_resources(struct pci_dev *dev, int mask)
>  	pci_read_config_word(dev, PCI_COMMAND, &cmd);
>  	old_cmd = cmd;
>  
> +	dev_info(&dev->dev, "%s: mask %#x old_cmd %#x\n", __func__, mask, old_cmd);
> +
>  	for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>  		if (!(mask & (1 << i)))
>  			continue;
>  
>  		r = &dev->resource[i];
> +		dev_info(&dev->dev, "  BAR %d %pR parent %p\n", i, r, r->parent);
>  
>  		if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
>  			continue;
> @@ -394,6 +397,7 @@ int pci_enable_resources(struct pci_dev *dev, int mask)
>  			cmd |= PCI_COMMAND_MEMORY;
>  	}
>  
> +	dev_info(&dev->dev, "%s: cmd %#x\n", __func__, cmd);
>  	if (cmd != old_cmd) {
>  		dev_info(&dev->dev, "enabling device (%04x -> %04x)\n",
>  			 old_cmd, cmd);
> 
You can see complete bootlog with above at
http://pastebin.ubuntu.com/15416575/

Let me know what you find.

Murali

-- 
Murali Karicheri
Linux Kernel, Keystone

  reply	other threads:[~2016-03-18 18:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 16:20 PCI IO resource question Murali Karicheri
2016-03-16 16:45 ` Bjorn Helgaas
2016-03-16 18:08   ` Murali Karicheri
2016-03-16 19:29     ` Bjorn Helgaas
2016-03-16 20:13       ` Murali Karicheri
2016-03-16 21:47         ` Bjorn Helgaas
2016-03-17 17:11           ` Murali Karicheri
2016-03-17 21:28           ` Murali Karicheri
2016-03-18 11:28             ` Lorenzo Pieralisi
2016-03-18 14:13               ` Bjorn Helgaas
2016-03-18 15:09               ` Murali Karicheri
2016-03-18 15:25                 ` Murali Karicheri
2016-03-18 15:28                 ` Bjorn Helgaas
2016-03-18 18:12                   ` Murali Karicheri [this message]
2016-03-18 19:34                     ` Bjorn Helgaas
2016-03-18 19:51                       ` Murali Karicheri
2016-03-18 23:05                 ` Lorenzo Pieralisi
2016-03-21 15:24                   ` Murali Karicheri
2016-03-21 18:02                     ` Lorenzo Pieralisi
2016-03-22 19:41                       ` Murali Karicheri
2016-03-23 22:02                         ` Lorenzo Pieralisi
2016-03-16 18:09 ` Lorenzo Pieralisi
2016-03-16 19:32   ` Bjorn Helgaas
2016-03-16 20:33   ` Murali Karicheri

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=56EC4523.9010304@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    /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;
as well as URLs for NNTP newsgroup(s).