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
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
