| Message ID | 1385429290-25397-11-git-send-email-yinghai@kernel.org |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu <yinghai@kernel.org> wrote: > That bar could be 64bit pref mem and above 4G. > > -v2: refresh to 3.13-rc1 > > Signed-off-by: Yinghai Lu <yinghai@kernel.org> > Cc: David Airlie <airlied@linux.ie> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> This looks OK to me. Does it depend on any previous patches in this series? If not, I think Dave should pick it up. Bjorn > --- > drivers/char/agp/intel-gtt.c | 14 ++++++++++---- > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c > index b8e2014..b929e9d 100644 > --- a/drivers/char/agp/intel-gtt.c > +++ b/drivers/char/agp/intel-gtt.c > @@ -609,8 +609,10 @@ static bool intel_gtt_can_wc(void) > static int intel_gtt_init(void) > { > u32 gma_addr; > + u32 addr_hi = 0; > u32 gtt_map_size; > int ret; > + int pos; > > ret = intel_private.driver->setup(); > if (ret != 0) > @@ -660,13 +662,17 @@ static int intel_gtt_init(void) > } > > if (INTEL_GTT_GEN <= 2) > - pci_read_config_dword(intel_private.pcidev, I810_GMADDR, > - &gma_addr); > + pos = I810_GMADDR; > else > - pci_read_config_dword(intel_private.pcidev, I915_GMADDR, > - &gma_addr); > + pos = I915_GMADDR; > + > + pci_read_config_dword(intel_private.pcidev, pos, &gma_addr); > + > + if (gma_addr & PCI_BASE_ADDRESS_MEM_TYPE_64) > + pci_read_config_dword(intel_private.pcidev, pos + 4, &addr_hi); > > intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK); > + intel_private.gma_bus_addr |= (u64)addr_hi << 32; > > return 0; > } > -- > 1.8.1.4 > -- 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
On Mon, Nov 25, 2013 at 7:46 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu <yinghai@kernel.org> wrote: >> That bar could be 64bit pref mem and above 4G. >> >> -v2: refresh to 3.13-rc1 >> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org> >> Cc: David Airlie <airlied@linux.ie> >> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > This looks OK to me. Does it depend on any previous patches in this > series? If not, I think Dave should pick it up. No. could be exposed after 5-9 get applied. Yinghai -- 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
On Tue, Nov 26, 2013 at 12:35 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Mon, Nov 25, 2013 at 7:46 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu <yinghai@kernel.org> wrote: >>> That bar could be 64bit pref mem and above 4G. >>> >>> -v2: refresh to 3.13-rc1 >>> >>> Signed-off-by: Yinghai Lu <yinghai@kernel.org> >>> Cc: David Airlie <airlied@linux.ie> >>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> >> >> This looks OK to me. Does it depend on any previous patches in this >> series? If not, I think Dave should pick it up. > > No. > > could be exposed after 5-9 get applied. Doesn't that mean that this series should be reordered so this patch is *before* patches 5-9 to avoid bisection breakage? I know you've split up and reposted parts of the series, but the question still applies. 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
On Wed, Dec 11, 2013 at 10:48 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: > > Doesn't that mean that this series should be reordered so this patch > is *before* patches 5-9 to avoid bisection breakage? I know you've > split up and reposted parts of the series, but the question still > applies. Yes, you are right. Maybe we have this one go through via Dave Airlie at first for 3.13? Thanks Yinghai -- 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
On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu <yinghai@kernel.org> wrote: > That bar could be 64bit pref mem and above 4G. > > -v2: refresh to 3.13-rc1 > > Signed-off-by: Yinghai Lu <yinghai@kernel.org> > Cc: David Airlie <airlied@linux.ie> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/char/agp/intel-gtt.c | 14 ++++++++++---- > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c > index b8e2014..b929e9d 100644 > --- a/drivers/char/agp/intel-gtt.c > +++ b/drivers/char/agp/intel-gtt.c > @@ -609,8 +609,10 @@ static bool intel_gtt_can_wc(void) > static int intel_gtt_init(void) > { > u32 gma_addr; > + u32 addr_hi = 0; > u32 gtt_map_size; > int ret; > + int pos; > > ret = intel_private.driver->setup(); > if (ret != 0) > @@ -660,13 +662,17 @@ static int intel_gtt_init(void) > } > > if (INTEL_GTT_GEN <= 2) > - pci_read_config_dword(intel_private.pcidev, I810_GMADDR, > - &gma_addr); > + pos = I810_GMADDR; > else > - pci_read_config_dword(intel_private.pcidev, I915_GMADDR, > - &gma_addr); > + pos = I915_GMADDR; > + > + pci_read_config_dword(intel_private.pcidev, pos, &gma_addr); > + > + if (gma_addr & PCI_BASE_ADDRESS_MEM_TYPE_64) > + pci_read_config_dword(intel_private.pcidev, pos + 4, &addr_hi); 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. And I'm confused because the i915_gmch_probe() path fills in gtt->mappable_base with the bus address, but the gen6_gmch_probe() path uses the resource, i.e., the CPU, address. That looks broken to me. agp_serverworks_probe() looks like another place that should not be reading the BARs directly. > > intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK); > + intel_private.gma_bus_addr |= (u64)addr_hi << 32; > > return 0; > } > -- > 1.8.1.4 > -- 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
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index b8e2014..b929e9d 100644 --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -609,8 +609,10 @@ static bool intel_gtt_can_wc(void) static int intel_gtt_init(void) { u32 gma_addr; + u32 addr_hi = 0; u32 gtt_map_size; int ret; + int pos; ret = intel_private.driver->setup(); if (ret != 0) @@ -660,13 +662,17 @@ static int intel_gtt_init(void) } if (INTEL_GTT_GEN <= 2) - pci_read_config_dword(intel_private.pcidev, I810_GMADDR, - &gma_addr); + pos = I810_GMADDR; else - pci_read_config_dword(intel_private.pcidev, I915_GMADDR, - &gma_addr); + pos = I915_GMADDR; + + pci_read_config_dword(intel_private.pcidev, pos, &gma_addr); + + if (gma_addr & PCI_BASE_ADDRESS_MEM_TYPE_64) + pci_read_config_dword(intel_private.pcidev, pos + 4, &addr_hi); intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK); + intel_private.gma_bus_addr |= (u64)addr_hi << 32; return 0; }