23 Feb, 2011

1 commit


18 Nov, 2010

2 commits

  • Support more than just the "Misc Control" part of the northbridges.
    Support more flags by turning "gart_supported" into a single bit flag
    that is stored in a flags member. Clean up related code by using a set
    of functions (amd_nb_num(), amd_nb_has_feature() and node_to_amd_nb())
    instead of accessing the NB data structures directly. Reorder the
    initialization code and put the GART flush words caching in a separate
    function.

    Signed-off-by: Hans Rosenfeld
    Signed-off-by: Borislav Petkov

    Hans Rosenfeld
     
  • Not only the naming of the files was confusing, it was even more so for
    the function and variable names.

    Renamed the K8 NB and NUMA stuff that is also used on other AMD
    platforms. This also renames the CONFIG_K8_NUMA option to
    CONFIG_AMD_NUMA and the related file k8topology_64.c to
    amdtopology_64.c. No functional changes intended.

    Signed-off-by: Hans Rosenfeld
    Signed-off-by: Borislav Petkov

    Hans Rosenfeld
     

22 Oct, 2010

1 commit

  • …/git/tip/linux-2.6-tip

    * 'x86-amd-nb-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, amd_nb: Enable GART support for AMD family 0x15 CPUs
    x86, amd: Use compute unit information to determine thread siblings
    x86, amd: Extract compute unit information for AMD CPUs
    x86, amd: Add support for CPUID topology extension of AMD CPUs
    x86, nmi: Support NMI watchdog on newer AMD CPU families
    x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
    x86, k8: Rename k8.[ch] to amd_nb.[ch] and CONFIG_K8_NB to CONFIG_AMD_NB
    x86, k8-gart: Decouple handling of garts and northbridges
    x86, cacheinfo: Fix dependency of AMD L3 CID
    x86, kvm: add new AMD SVM feature bits
    x86, cpu: Fix allowed CPUID bits for KVM guests
    x86, cpu: Update AMD CPUID feature bits
    x86, cpu: Fix renamed, not-yet-shipping AMD CPUID feature bit
    x86, AMD: Remove needless CPU family check (for L3 cache info)
    x86, tsc: Remove CPU frequency calibration on AMD

    Linus Torvalds
     

21 Sep, 2010

1 commit


18 Sep, 2010

1 commit

  • So far we only provide num_k8_northbridges. This is required in
    different areas (e.g. L3 cache index disable, GART). But not all AMD
    CPUs provide a GART. Thus it is useful to split off the GART handling
    from the generic caching of AMD northbridge misc devices.

    Signed-off-by: Andreas Herrmann
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Andreas Herrmann
     

05 Sep, 2010

2 commits

  • Current code tramples over bit F3x90[6] which can be used to
    disable GART table walk probes. However, this bit should be set
    for performance reasons (speed up GART table walks). We are
    allowed to do that since we put GART tables in UC memory later
    anyway. Make it so.

    Signed-off-by: Borislav Petkov
    Cc: Dave Airlie
    Cc: FUJITA Tomonori
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Borislav Petkov
     
  • There is a GARTEN so use that and drop the duplicate.

    Signed-off-by: Borislav Petkov
    Cc: Dave Airlie
    Cc: FUJITA Tomonori
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Borislav Petkov
     

26 May, 2010

1 commit

  • Stanse found pci reference leaks in uli_agp_init and nforce3_agp_init
    initialization functions.

    The PCI devices are bridges, so it's not critical, but still worth fixing.

    Signed-off-by: Jiri Slaby
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Airlie

    Jiri Slaby
     

19 May, 2010

1 commit

  • The current initialisation code probes 'unsupported' AGP devices
    simply by calling its own probe function. It does not lock these
    devices or even check whether another driver is already bound to
    them.

    We must use the device core to manage this. So if the specific
    device id table didn't match anything and agp_try_unsupported=1,
    switch the device id table and call driver_attach() again.

    Signed-off-by: Ben Hutchings
    Signed-off-by: Dave Airlie

    Ben Hutchings
     

23 Apr, 2010

1 commit

  • Convert most AGP chipset to use scratch page as default entries.
    This help avoiding GPU querying 0 address and trigger computer
    fault. With KMS and memory manager we bind/unbind AGP memory
    constantly and it seems that some GPU are still doing AGP
    traffic even after GPU report being idle with the memory segment.

    Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on :
    - SIS 1039:0001 & 1039:0003
    - Intel 865 8086:2571

    Compile tested for other bridges

    V2 enable scratch page on uninorth
    V3 fix unbound check in uninorth insert memory (Michel Dänzer)
    V4 rebase on top of drm-next branch with the lastest intel AGP
    changeset (stable should use version V3 of the patch)

    Signed-off-by: Jerome Glisse
    Signed-off-by: Michel Dänzer
    Signed-off-by: Dave Airlie

    Jerome Glisse
     

04 Feb, 2010

1 commit

  • This fixes the regression introduced by commit
    42590a75019a50012f25a962246498dead428433 ("x86/agp: Fix
    agp_amd64_init and agp_amd64_cleanup").

    The commit 61684ceaad4f65d1a9832c722f7bd5e7fc714de9 fixed the
    above regression but it's not enough. When amd64-agp is built as
    a module, AGP isn't initialized, iommu is initialized, all the
    aperture is owned by the iommu.

    Reported-by: Marin Mitov
    Signed-off-by: FUJITA Tomonori
    Tested-by: Marin Mitov
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    FUJITA Tomonori
     

31 Jan, 2010

1 commit

  • This fixes the regression introduced by commit
    42590a75019a50012f25a962246498dead428433 ("x86/agp: Fix
    agp_amd64_init and agp_amd64_cleanup").

    The above commit changes agp_amd64_init() not to do anything if
    gart_iommu_aperture is not zero.

    If GART iommu calls agp_amd64_init(), we need to skip
    agp_amd64_init() when it's called later via module_init.

    The problem is that gart_iommu_init() calls agp_amd64_init()
    with not zero gart_iommu_aperture so agp_amd64_init() is never
    initialized.

    When gart_iommu_init() calls agp_amd64_init(), agp should be
    always initialized.

    Reported-by: Marin Mitov
    Reported-by: Johannes Hirte
    Signed-off-by: FUJITA Tomonori
    Tested-by: Marin Mitov
    Tested-by: Kevin Winchester
    Cc: davej@redhat.com
    Cc: Linus Torvalds
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    FUJITA Tomonori
     

13 Jan, 2010

1 commit

  • This fixes the regression introduced by the commit
    f405d2c02395a74d3883bd03ded36457aa3697ad.

    The above commit fixes the following issue:

    http://marc.info/?l=linux-kernel&m=126192729110083&w=2

    However, it doesn't work properly when you remove and insert the
    agp_amd64 module again.

    agp_amd64_init() and agp_amd64_cleanup should be called only
    when gart_iommu is not called earlier (that is, the GART IOMMU
    is not enabled). We need to use 'gart_iommu_aperture' to see if
    GART IOMMU is enabled or not.

    Signed-off-by: FUJITA Tomonori
    Cc: mitov@issp.bas.bg
    Cc: davej@redhat.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    FUJITA Tomonori
     

30 Dec, 2009

1 commit

  • with CONFIG_GART_IOMMU enabled drivers/char/agp/amd64-agp.c has:

    #ifndef CONFIG_GART_IOMMU
    module_init(agp_amd64_init);
    module_exit(agp_amd64_cleanup);
    #endif

    agp_amd64_init() was called via gart_iommu_init with
    CONFIG_GART_IOMMU=y agp_amd64_init() was called via module_init
    with CONFIG_GART_IOMMU=n

    The commit 75f1cdf1dda92cae037ec848ae63690d91913eac changes the
    x86 dma initialization routine: gart_iommu_init() is called only
    when GART IOMMU is detected. So when GART IOMMU isn't detected,
    agp_amd64_init isn't called.

    Marin Mitov reported this issue:

    http://marc.info/?l=linux-kernel&m=126192729110083&w=2

    With this patch, agp_amd64_init() is always called via
    module_init (the above ifndef is removed). If agp_amd64_init()
    is called via gart_iommu_init() earlier, agp_amd64_init()
    finishes without doing anything (when it is called via
    module_init).

    Reported-by: Marin Mitov
    Tested-by: Marin Mitov
    Signed-off-by: FUJITA Tomonori
    Cc: davej@redhat.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    FUJITA Tomonori
     

03 Aug, 2009

2 commits


19 Jun, 2009

1 commit


11 Mar, 2009

1 commit

  • Impact: fix bug to make agp work with dri

    Jeffrey reported that dri does work with 64bit, but doesn't work with
    32bit it turns out NB aperture is 32M, aperture on agp is 128M

    64bit is using 64M for vaidation for 64 iommu/gart 32bit is only using
    32M..., and will not update the nb aperture.

    So try to compare nb apterture and agp apterture before leaving not
    touch nb aperture.

    Reported-by: Jeffrey Trull
    Tested-by: Jeffrey Trull
    Signed-off-by: Yinghai Lu
    Acked-by: Dave Airlie
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yinghai Lu
     

21 Oct, 2008

1 commit

  • Update assorted email addresses and related info to point
    to a single current, valid address.

    additionally
    - trivial CREDITS entry updates. (Not that this file means much any more)
    - remove arjans dead redhat.com address from powernow driver

    Signed-off-by: Dave Jones
    Signed-off-by: Linus Torvalds

    Dave Jones
     

22 Aug, 2008

1 commit

  • The pageattr-array patch that you currently have in tip/master only
    enables it for intel-agp, not the others. The attached enables it for
    all drivers currently directly using agp_generic_alloc_page() and
    agp_generic_destroy_page() (ocal driver is amd-k7-agp).

    The new agp_generic_alloc_pages() interface uses the also new
    pageattr array interface API. This makes all AGP drivers that
    up to now used generic_{alloc,destroy}_page() use it.

    Signed-off-by: Rene Herman
    Signed-off-by: Ingo Molnar

    Rene Herman
     

12 Aug, 2008

2 commits


25 Jun, 2008

1 commit


19 Jun, 2008

1 commit


22 May, 2008

1 commit


13 May, 2008

4 commits

  • Cleanup gart handling on amd64 a bit: move common code into
    enable_gart_translation , and use symbolic register names where
    appropriate.

    Signed-off-by: Pavel Machek
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Pavel Machek
     
  • some systems are using 32M for gart and agp when memory is less than 4G.
    Kernel will reject and try to allcate another 64M that is not needed,
    and we will waste 64M of perfectly good RAM.

    this patch adds a workaround by checking aper_base/order between NB and
    agp bridge. If they are the same, and memory size is less than 4G, it
    will allow it.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     
  • while looking at Rafael J. Wysocki's system boot log,

    I found a funny printout:

    Node 0: aperture @ de000000 size 32 MB
    Aperture too small (32 MB)
    AGP bridge at 00:04:00
    Aperture from AGP @ de000000 size 4096 MB (APSIZE 0)
    Aperture too small (0 MB)
    Your BIOS doesn't leave a aperture memory hole
    Please enable the IOMMU option in the BIOS setup
    This costs you 64 MB of RAM
    Mapping aperture over 65536 KB of RAM @ 4000000

    ...

    agpgart: Detected AGP bridge 20
    agpgart: Aperture pointing to RAM
    agpgart: Aperture from AGP @ de000000 size 4096 MB
    agpgart: Aperture too small (0 MB)
    agpgart: No usable aperture found.
    agpgart: Consider rebooting with iommu=memaper=2 to get a good aperture.

    it means BIOS allocated the correct gart on the NB and AGP bridge, but
    because a bug in the silicon (the agp bridge reports the wrong order,
    it wants 4G instead) the kernel will reject that allocation.

    Also, because the size is only 32MB, and we try to get another 64M for gart,
    late fix_northbridge can not revert that change because it still reads
    the wrong size from agp bridge.

    So try to double check the order value from the agp bridge, before calling
    aperture_valid().

    [ mingo@elte.hu: 32-bit fix. ]

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     
  • Move symbolic constants into gart.h, and use them instead of hardcoded
    constant.

    Signed-off-by: Pavel Machek
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Pavel Machek
     

30 Oct, 2007

1 commit


12 Jul, 2007

1 commit

  • Instead of all drivers reading pci config space to get the revision
    ID, they can now use the pci_device->revision member.

    This exposes some issues where drivers where reading a word or a dword
    for the revision number, and adding useless error-handling around the
    read. Some drivers even just read it for no purpose of all.

    In devices where the revision ID is being copied over and used in what
    appears to be the equivalent of hotpath, I have left the copy code
    and the cached copy as not to influence the driver's performance.

    Compile tested with make all{yes,mod}config on x86_64 and i386.

    Signed-off-by: Auke Kok
    Acked-by: Dave Jones
    Signed-off-by: Greg Kroah-Hartman

    Auke Kok
     

12 May, 2007

1 commit

  • I'm using a custom BIOS to configure the northbridge GART at address
    0x80000000, size 2G. Linux complains:

    "Aperture from northbridge cpu 0 beyond 4GB. Ignoring."

    I think there's an off-by-two error in arch/x86_64/kernel/aperture.c:

    AK: use correct types for i386

    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Andrew Hastings
     

03 May, 2007

1 commit

  • Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
    subsequent pfn-s are also invalid is wrong. Thus replace this by
    explicitly checking against the E820 map.

    AK: make e820 on x86-64 not initdata

    Signed-off-by: Jan Beulich
    Signed-off-by: Andi Kleen
    Acked-by: Mark Langsdorf

    Jan Beulich
     

23 Feb, 2007

1 commit


04 Feb, 2007

1 commit

  • This patch allows drm to populate an agpgart structure with pages of its own.
    It's needed for the new drm memory manager which dynamically flips pages in and out of AGP.

    The patch modifies the generic functions as well as the intel agp driver. The intel drm driver is
    currently the only one supporting the new memory manager.

    Other agp drivers may need some minor fixing up once they have a corresponding memory manager enabled drm driver.

    AGP memory types >= AGP_USER_TYPES are not populated by the agpgart driver, but the drm is expected
    to do that, as well as taking care of cache- and tlb flushing when needed.

    It's not possible to request these types from user space using agpgart ioctls.

    The Intel driver also gets a new memory type for pages that can be bound cached to the intel GTT.

    Signed-off-by: Thomas Hellstrom
    Signed-off-by: Dave Jones

    Thomas Hellstrom
     

29 Jan, 2007

1 commit


19 Dec, 2006

1 commit


08 Dec, 2006

1 commit

  • When CONFIG_HOTPLUG=n, agp_amd64_resume() calls nforce3_agp_init(), which is
    __devinit == __init, so has been discarded and is not usable for resume.

    WARNING: drivers/char/agp/amd64-agp.o - Section mismatch: reference to .init.text: from .text between 'agp_amd64_resume' (at offset 0x249) and 'amd64_tlbflush'

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

27 Sep, 2006

1 commit