All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Alex Williamson <alex.williamson@hp.com>
Cc: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: Always set prefetchable base/limit upper32 registers
Date: Mon, 30 Nov 2009 16:00:29 -0800	[thread overview]
Message-ID: <4B145C9D.70601@kernel.org> (raw)
In-Reply-To: <1259625224.8949.319.camel@8530w.home>

Alex Williamson wrote:
> On Mon, 2009-11-30 at 15:32 -0800, Yinghai Lu wrote:
>> Alex Williamson wrote:
>>> On Mon, 2009-11-30 at 14:12 -0800, Yinghai Lu wrote:
>>>> Alex Williamson wrote: 
>>>>> I don't believe the PCI spec dictates whether the upper 32bit base
>>>>> should be 0 or -1, so it's purely a BIOS initialization choice and Linux
>>>>> should properly handle both.  If the hardware only supports 32bit
>>>>> prefetchable windows, the hardware will drop the write, just as it did
>>>>> for every 2.6 kernel before 1f82de10.  Thanks,
>>>> current code:
>>>>
>>>> #define  PCI_PREF_RANGE_TYPE_MASK 0x0fUL
>>>> #define  PCI_PREF_RANGE_TYPE_32 0x00     
>>>> #define  PCI_PREF_RANGE_TYPE_64 0x01
>>>> #define  PCI_PREF_RANGE_MASK    (~0x0fUL)
>>>>
>>>> if the HW state the pref mmio is 64bit, we will touch upper 32bit. otherwise we will not touch it.
>>> Really, where?  Please paste the code that writes to
>>> PCI_PREF_BASE_UPPER32 in the case of hardware supporting a 64bit
>>> prefetchable window.  I only see this happening if we are assigning it
>>> to an IORESOURCE_MEM_64 resources.
>> IORESOURCE_MEM_64 get set when PCI_PREF_RANGE_TYPE_64 is set.
>>
>> in probe.c::pci_read_bridge_bases()
> 
> Ah, I think I see where you're going.  We only set IORESOURCE_MEM_64 if
> base <= limit, ie. the BIOS has programmed the prefetchable range.  This
> is not a requirement by the PCI spec.  In my case the BIOS has left base
>> limit, just as Linux would do if it disabled the range, so we never
> set this flag.
> 
>> setup-bus.c::pci_bridge_check_ranges()
> 
> This is only checking that the upper 32bits is actually implemented,
> should we have already set the IORESOURCE_MEM_64 from the function
> above, which we haven't.  
> 
> So, in my case I have a 64bit capable prefetchable range, that the BIOS
> has not programmed and is not required to program.  We assign it to a
> 32bit window, and never touch the UPPER32 registers.

no.

before assign range to that resource.
pci_bridge_check_ranges is called, it will check those two bit to make sure that is set correcly

        if (pmem) {
                b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH;
                if ((pmem & PCI_PREF_RANGE_TYPE_MASK) == PCI_PREF_RANGE_TYPE_64)
                        b_res[2].flags |= IORESOURCE_MEM_64;
        }

        /* double check if bridge does support 64 bit pref */
        if (b_res[2].flags & IORESOURCE_MEM_64) {
                u32 mem_base_hi, tmp;
                pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
                                         &mem_base_hi);
                pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
                                               0xffffffff);
                pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32, &tmp);
                if (!tmp)
                        b_res[2].flags &= ~IORESOURCE_MEM_64;
                pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
                                       mem_base_hi);
        }

so even with 32 bit window in 64bit BAR, that upper32 bit still get cleared.

YH

  reply	other threads:[~2009-12-01  0:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30 21:22 [PATCH] PCI: Always set prefetchable base/limit upper32 registers Alex Williamson
2009-11-30 21:36 ` Yinghai Lu
2009-11-30 21:43   ` Alex Williamson
2009-11-30 21:52     ` Yinghai Lu
2009-11-30 22:01       ` Alex Williamson
2009-11-30 22:12         ` Yinghai Lu
2009-11-30 22:19           ` Alex Williamson
2009-11-30 23:32             ` Yinghai Lu
2009-11-30 23:53               ` Alex Williamson
2009-12-01  0:00                 ` Yinghai Lu [this message]
2009-12-01  1:56                   ` Alex Williamson
2009-12-01  2:26                     ` Yinghai Lu
2009-12-01  2:50                       ` Yinghai Lu
2009-12-01  3:23                         ` Alex Williamson
2009-12-01  6:35                           ` Yinghai Lu
2009-12-01  6:55                             ` Alex Williamson
2009-12-01  7:03                             ` [PATCH] pci: fix bridge 64bit flag setting Yinghai Lu
2009-12-01 15:38                               ` Bjorn Helgaas
2009-12-01 18:28                                 ` Yinghai Lu
2009-12-01 19:15                                   ` Yinghai Lu
2009-12-01  0:22                 ` [PATCH] PCI: Always set prefetchable base/limit upper32 registers Yinghai Lu
2009-12-01  0:00               ` Grant Grundler
2009-12-01  0:09                 ` Yinghai Lu
2009-12-01  0:15                   ` Grant Grundler
2009-11-30 23:58       ` Grant Grundler
2009-11-30 21:42 ` Grant Grundler
2009-11-30 21:43   ` Alex Williamson

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=4B145C9D.70601@kernel.org \
    --to=yinghai@kernel.org \
    --cc=alex.williamson@hp.com \
    --cc=jbarnes@virtuousgeek.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.