From: Bjorn Helgaas <bhelgaas@google.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Gu Zheng <guz.fnst@cn.fujitsu.com>,
Guo Chao <yan@linux.vnet.ibm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v2 10/10] intel-gtt: Read 64bit for gmar_bus_addr
Date: Sat, 21 Dec 2013 11:50:45 -0700 [thread overview]
Message-ID: <20131221185045.GA22728@google.com> (raw)
In-Reply-To: <CAE9FiQUDkuBnuYo4OfZncFw6k22PcapgjqzapVFt5UneiqoVDQ@mail.gmail.com>
[+cc Daniel]
On Fri, Dec 20, 2013 at 05:19:38PM -0800, Yinghai Lu wrote:
> On Fri, Dec 20, 2013 at 4:27 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>
> > Why are we reading these BARs directly anyway? These look like
> > standard PCI BARs (I810_GMADDR == 0x10 and I915_GMADDR == 0x18), so
> > the PCI core should already be reading them correctly, shouldn't it?
> > Can't we just use pcibios_resource_to_bus(pci_resource_start())?
> >
> > It looks like i810_setup(), i830_setup(), and i9xx_setup() have the
> > same problem and should also be using pci_resource_start() or
> > something similar.
>
> Agreed.
>
> should be sth like:
>
>
> Index: linux-2.6/drivers/char/agp/intel-gtt.c
> ===================================================================
> --- linux-2.6.orig/drivers/char/agp/intel-gtt.c
> +++ linux-2.6/drivers/char/agp/intel-gtt.c
> @@ -608,9 +608,9 @@ static bool intel_gtt_can_wc(void)
>
> static int intel_gtt_init(void)
> {
> - u32 gma_addr;
> + struct pci_bus_region r;
> u32 gtt_map_size;
> - int ret;
> + int ret, idx;
>
> ret = intel_private.driver->setup();
> if (ret != 0)
> @@ -660,13 +660,14 @@ static int intel_gtt_init(void)
> }
>
> if (INTEL_GTT_GEN <= 2)
> - pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
> - &gma_addr);
> + idx = 0; /* I810_GMADDR */
> else
> - pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
> - &gma_addr);
> + idx = 2; /* I915_GMADDR */
>
> - intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
> + pcibios_resource_to_bus(intel_private.pcidev->bus, &r,
> + &intel_private.pcidev->resource[idx]);
> +
> + intel_private.gma_bus_addr = r.start;
>
> return 0;
> }
I think it's even worse than we first thought. Not only does the current
code fail on 64-bit BARs, but it also ignores the CPU/bus address
difference, and I think we want the CPU address. So I think we need
something like these:
commit 8ba262d78f9d218672486c62ba6a1c7a073bd272
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Sat Dec 21 10:49:58 2013 -0700
agp/intel: Rename "*_bus_addr" to "*_phys_addr"
We're dealing with CPU physical addresses here, which may be different from
bus addresses, so rename "gtt_bus_addr" to "gtt_phys_addr" and
"gma_bus_addr" to "gma_phys_addr" to avoid confusion.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index b8e2014cb9cb..dca04a6aa7f8 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -64,7 +64,7 @@ static struct _intel_private {
struct pci_dev *pcidev; /* device one */
struct pci_dev *bridge_dev;
u8 __iomem *registers;
- phys_addr_t gtt_bus_addr;
+ phys_addr_t gtt_phys_addr;
u32 PGETBL_save;
u32 __iomem *gtt; /* I915G */
bool clear_fake_agp; /* on first access via agp, fill with scratch */
@@ -78,7 +78,7 @@ static struct _intel_private {
int refcount;
/* Whether i915 needs to use the dmar apis or not. */
unsigned int needs_dmar : 1;
- phys_addr_t gma_bus_addr;
+ phys_addr_t gma_phys_addr;
/* Size of memory reserved for graphics by the BIOS */
unsigned int stolen_size;
/* Total number of gtt entries. */
@@ -191,7 +191,7 @@ static int i810_setup(void)
writel(virt_to_phys(gtt_table) | I810_PGETBL_ENABLED,
intel_private.registers+I810_PGETBL_CTL);
- intel_private.gtt_bus_addr = reg_addr + I810_PTE_BASE;
+ intel_private.gtt_phys_addr = reg_addr + I810_PTE_BASE;
if ((readl(intel_private.registers+I810_DRAM_CTL)
& I810_DRAM_ROW_0) == I810_DRAM_ROW_0_SDRAM) {
@@ -636,10 +636,10 @@ static int intel_gtt_init(void)
intel_private.gtt = NULL;
if (intel_gtt_can_wc())
- intel_private.gtt = ioremap_wc(intel_private.gtt_bus_addr,
+ intel_private.gtt = ioremap_wc(intel_private.gtt_phys_addr,
gtt_map_size);
if (intel_private.gtt == NULL)
- intel_private.gtt = ioremap(intel_private.gtt_bus_addr,
+ intel_private.gtt = ioremap(intel_private.gtt_phys_addr,
gtt_map_size);
if (intel_private.gtt == NULL) {
intel_private.driver->cleanup();
@@ -666,7 +666,7 @@ static int intel_gtt_init(void)
pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
&gma_addr);
- intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
+ intel_private.gma_phys_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
return 0;
}
@@ -796,7 +796,7 @@ static int i830_setup(void)
if (!intel_private.registers)
return -ENOMEM;
- intel_private.gtt_bus_addr = reg_addr + I810_PTE_BASE;
+ intel_private.gtt_phys_addr = reg_addr + I810_PTE_BASE;
return 0;
}
@@ -821,7 +821,7 @@ static int intel_fake_agp_configure(void)
return -EIO;
intel_private.clear_fake_agp = true;
- agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
+ agp_bridge->gart_bus_addr = intel_private.gma_phys_addr;
return 0;
}
@@ -1123,13 +1123,13 @@ static int i9xx_setup(void)
case 3:
pci_read_config_dword(intel_private.pcidev,
I915_PTEADDR, >t_addr);
- intel_private.gtt_bus_addr = gtt_addr;
+ intel_private.gtt_phys_addr = gtt_addr;
break;
case 5:
- intel_private.gtt_bus_addr = reg_addr + MB(2);
+ intel_private.gtt_phys_addr = reg_addr + MB(2);
break;
default:
- intel_private.gtt_bus_addr = reg_addr + KB(512);
+ intel_private.gtt_phys_addr = reg_addr + KB(512);
break;
}
@@ -1409,7 +1409,7 @@ void intel_gtt_get(size_t *gtt_total, size_t *stolen_size,
{
*gtt_total = intel_private.gtt_total_entries << PAGE_SHIFT;
*stolen_size = intel_private.stolen_size;
- *mappable_base = intel_private.gma_bus_addr;
+ *mappable_base = intel_private.gma_phys_addr;
*mappable_end = intel_private.gtt_mappable_entries << PAGE_SHIFT;
}
EXPORT_SYMBOL(intel_gtt_get);
commit 31349de4ce32a0c2c2d14df35717544e94d56066
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Sat Dec 21 10:09:19 2013 -0700
intel-gtt: Use CPU address (not BAR value) for GART
There were two problems here:
1) The GMADR can be either a 32-bit or a 64-bit BAR, but we only read the
low 32 bits, so this failed if GMADR was above 4GB.
2) The value read from the BAR is a bus address, not a CPU physical
address, and these may be different.
Use pci_resource_start() instead of reading the BAR directly to remove the
BAR size and bus/CPU address issue, as gen8_gmch_probe() already does.
Reference: http://lkml.kernel.org/r/1385429290-25397-11-git-send-email-yinghai@kernel.org
Based-on-patch-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index dca04a6aa7f8..35169ff0ffe1 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -610,7 +610,7 @@ static int intel_gtt_init(void)
{
u32 gma_addr;
u32 gtt_map_size;
- int ret;
+ int ret, bar;
ret = intel_private.driver->setup();
if (ret != 0)
@@ -660,14 +660,12 @@ static int intel_gtt_init(void)
}
if (INTEL_GTT_GEN <= 2)
- pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
- &gma_addr);
+ bar = 0; /* I810_GMADDR */
else
- pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
- &gma_addr);
-
- intel_private.gma_phys_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
+ bar = 2; /* I915_GMADDR */
+ intel_private.gma_phys_addr = pci_resource_start(intel_private.pcidev,
+ bar);
return 0;
}
next prev parent reply other threads:[~2013-12-21 18:50 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 1:28 [PATCH v2 00/10] PCI: Double removing fix and allocate 64bit mmio pref Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 01/10] PCI: Use device_release_driver in pci_stop_root_bus Yinghai Lu
2013-11-27 1:09 ` Rafael J. Wysocki
2013-11-26 1:28 ` [PATCH v2 02/10] PCI: Move back pci_proc_attach_devices calling Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 03/10] PCI: Move resources and bus_list releasing to pci_release_dev Yinghai Lu
2013-11-27 1:15 ` Rafael J. Wysocki
2013-11-27 2:15 ` Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 04/10] PCI: Destroy pci dev only once Yinghai Lu
2013-11-26 3:38 ` Bjorn Helgaas
2013-11-26 19:34 ` Yinghai Lu
2013-11-26 20:13 ` Yinghai Lu
2013-11-27 1:24 ` Rafael J. Wysocki
2013-11-27 2:26 ` Yinghai Lu
2013-11-29 23:38 ` Rafael J. Wysocki
2013-11-29 23:45 ` Rafael J. Wysocki
2013-11-30 0:31 ` Rafael J. Wysocki
2013-11-30 21:37 ` Rafael J. Wysocki
2013-11-30 22:27 ` Yinghai Lu
2013-12-01 1:24 ` Rafael J. Wysocki
2013-12-02 1:29 ` Rafael J. Wysocki
2013-12-02 14:49 ` Rafael J. Wysocki
2013-12-05 22:40 ` Bjorn Helgaas
2013-12-06 1:21 ` Rafael J. Wysocki
2013-12-06 6:29 ` Yinghai Lu
2014-01-10 14:20 ` [PATCH 0/9] PCI: Eliminate race conditions between hotplug and sysfs rescan/remove (Was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once) Rafael J. Wysocki
2014-01-10 14:22 ` [PATCH 1/9] PCI: Global rescan-remove lock Rafael J. Wysocki
2014-01-10 14:23 ` [PATCH 2/9] ACPI / PCI: Use global PCI rescan-remove locking in PCI root hotplug Rafael J. Wysocki
2014-01-10 14:24 ` [PATCH 3/9] ACPI / hotplug / PCI: Use global PCI rescan-remove locking Rafael J. Wysocki
2014-01-10 14:25 ` [PATCH 4/9] PCMCIA / cardbus: " Rafael J. Wysocki
2014-01-10 14:26 ` [PATCH 5/9] PCI / hotplug: " Rafael J. Wysocki
2014-01-10 14:27 ` [PATCH 6/9] platform / x86: " Rafael J. Wysocki
2014-01-10 14:27 ` [PATCH 7/9] MPT / PCI: Use pci_stop_and_remove_bus_device_locked() Rafael J. Wysocki
2014-01-10 14:28 ` [PATCH 8/9] powerpc / eeh_driver: Use global PCI rescan-remove locking Rafael J. Wysocki
2014-01-15 13:36 ` [Update][PATCH " Rafael J. Wysocki
2014-01-15 17:38 ` Bjorn Helgaas
2014-01-10 14:29 ` [PATCH 9/9] Xen / PCI: " Rafael J. Wysocki
2014-01-15 18:02 ` [PATCH 0/9] PCI: Eliminate race conditions between hotplug and sysfs rescan/remove (Was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once) Bjorn Helgaas
2013-12-06 6:52 ` [PATCH v2 04/10] PCI: Destroy pci dev only once Yinghai Lu
2013-12-07 1:27 ` Rafael J. Wysocki
2013-12-08 3:31 ` Yinghai Lu
2013-12-08 3:50 ` Greg Kroah-Hartman
2013-12-09 15:24 ` Ethan Zhao
2013-12-09 19:08 ` Greg Kroah-Hartman
2013-12-10 7:43 ` Ethan Zhao
2014-01-13 1:03 ` [PATCH] PCI / remove: Check parent kobject in pci_destroy_dev() (was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once) Rafael J. Wysocki
2013-11-27 1:17 ` [PATCH v2 04/10] PCI: Destroy pci dev only once Rafael J. Wysocki
2013-11-26 1:28 ` [PATCH v2 05/10] PCI: pcibus address to resource converting take bus directly Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 06/10] PCI: Add pcibios_bus_addr_to_res() Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 07/10] PCI: Try to allocate mem64 above 4G at first Yinghai Lu
2013-11-26 4:15 ` Bjorn Helgaas
2013-11-26 20:14 ` Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 08/10] PCI: Try best to allocate pref mmio 64bit above 4g Yinghai Lu
2013-11-26 4:17 ` Bjorn Helgaas
2013-11-26 6:59 ` Guo Chao
2013-11-26 17:53 ` Bjorn Helgaas
2013-11-26 22:00 ` Yinghai Lu
2013-11-26 22:01 ` Bjorn Helgaas
2013-11-27 0:33 ` Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 09/10] PCI: Sort pci root bus resources list Yinghai Lu
2013-11-26 4:18 ` Bjorn Helgaas
2013-11-26 1:28 ` [PATCH v2 10/10] intel-gtt: Read 64bit for gmar_bus_addr Yinghai Lu
2013-11-26 3:46 ` Bjorn Helgaas
2013-11-26 19:35 ` Yinghai Lu
2013-12-11 18:48 ` Bjorn Helgaas
2013-12-11 19:58 ` Yinghai Lu
2013-12-21 0:27 ` Bjorn Helgaas
2013-12-21 1:19 ` Yinghai Lu
2013-12-21 18:50 ` Bjorn Helgaas [this message]
2013-12-23 22:33 ` Bjorn Helgaas
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=20131221185045.GA22728@google.com \
--to=bhelgaas@google.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@ffwll.ch \
--cc=guz.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=yan@linux.vnet.ibm.com \
--cc=yinghai@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.