lkml.org 
[lkml]   [2003]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Improved DRM support for cant_use_aperture platforms
    On Tue, May 13, 2003 at 09:20:09AM -0700, David Mosberger wrote:
    > Ivan> Note that some Alphas may have "cant_use_aperture" cleared.
    >
    > "Interesting".

    Yep. ;-)

    > If cant_use_aperture isn't set, my patch won't help, but it shouldn't
    > hurt anything either. I.e., you should be no worse off than before.

    Sure. Basically, I'll only need to re-diff.

    > What's the nature of those "ugly and fragile" hacks? Are you saying
    > that CPU accesses to AGP space aren't remapped in the "normal" (PC)
    > way? Or is it something entirely different?

    Ok, you asked for it... :-)
    As you know, Alpha architecture is entirely cache coherent
    by design, i.e. there are no such things as non-cacheable mappings
    or cache flushing in hardware. Native Alpha Titan/Marvel AGP controllers
    are also cache coherent (kind of AGP extension of traditional
    Alpha PCI IOMMU).
    However, the "normal" PC AGP implementation isn't - this applies
    to AMD-751/761 AGP controllers on Nautilus as well.
    The AGP window on these chipsets is accessible by CPU *only* in the
    system memory address space, i.e. it's always cacheable and thus
    totally useless on Alpha.
    Fortunately, AMD northbridges (at least 761) have some features
    that allow *limited* access to system memory, including AGP space,
    through EV6 non-cacheable IO address space (using "magic" 16 Gb offset).
    Limitations:
    - quadword writes corrupt ECC.
    EV6 doesn't generate ECC for IO space, but the chipset expects ECC
    from CPU on full quad writes (narrower writes are ok since the chipset
    does read-modify-write and updates ECC by itself).
    This wouldn't be a big deal since nobody should access pages mapped
    into AGP, but there are occasional speculative loads which hit data
    with bad ECC that causing the machine checks. So I must handle these
    machine checks properly - check that the page is AGP and then either
    scrub the affected location to fix ECC or dismiss the machine check.
    - according to AMD specs, reads to this "non-cacheable" region are
    not supported. Not quite true, as quadword loads (ldq/ldq_u) do work
    (verified on 761, 751 needs testing). Narrower loads indeed don't work.
    Fortunately, AGP space reads seem to be sort of exotic (in both
    kernel and userspace drivers), so they can be easily found and converted
    to ldq/ldq_u.

    In addition I cannot trust PALcode error handler on UP1500 - sometimes it
    does bogus things...
    By now I have all this crap running more or less stable with
    radeon 7200 card. Machine check handling needs some improvements though.

    Ivan.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:35    [W:4.022 / U:1.540 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site