Patchwork [v2,10/10] intel-gtt: Read 64bit for gmar_bus_addr

login
register
mail settings
Submitter Yinghai Lu
Date Nov. 26, 2013, 1:28 a.m.
Message ID <1385429290-25397-11-git-send-email-yinghai@kernel.org>
Download mbox | patch
Permalink /patch/294146/
State Superseded
Headers show

Comments

Yinghai Lu - Nov. 26, 2013, 1:28 a.m.
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(-)
Bjorn Helgaas - Nov. 26, 2013, 3:46 a.m.
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
Yinghai Lu - Nov. 26, 2013, 7:35 p.m.
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
Bjorn Helgaas - Dec. 11, 2013, 6:48 p.m.
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
Yinghai Lu - Dec. 11, 2013, 7:58 p.m.
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
Bjorn Helgaas - Dec. 21, 2013, 12:27 a.m.
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

Patch

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;
 }