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    [from the cache]
©2003-2011 Jasper Spaans