lkml.org 
[lkml]   [2004]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: radeon-pre-2
    >
    > I still haven't seen a complete logical chain leading to that
    > conclusion.
    >
    > The lowlevel driver could provide all the necessary arbitration and
    > safety measures to prevent the two from stepping on each other's toes.
    >

    The thing is I know of no way to provide arbitration in such a way as to
    permit other code to access PLL registers directly.

    One way or the other you will have to add "please set mode X" function to
    DRM and then the point of having a separate file for fb-con related 2d
    only is moot.

    Additional argument for this is that DRM *NEEDS* to know about mode
    setting so that when it detects an engine lockup it is able to restore the
    card to a sane state without FB driver.

    Right now there are two places where engine reset is handled: DRM driver
    (where we reset the chip and leave it as is, with mode all screwed up) and
    in Xserver (where we set the mode, but I have never seen this code path
    triggered).

    Thus at the very least you would want to mandate the availability of mode
    setting part of FB when DRM is loaded - and they you can just as well link
    the relevant code together.

    best

    Vladimir Dergachev
    -
    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 14:06    [W:0.023 / U:30.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site