Messages in this thread | | | Date | Sat, 11 Sep 2004 09:43:56 +0100 | From | Keith Whitwell <> | Subject | Re: radeon-pre-2 |
| |
Vladimir Dergachev wrote: > > Alan, > I would like to disagree with you. > > On Fri, 10 Sep 2004, Alan Cox wrote: > >> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote: >> >>> If the kernel developers can address this point I would be most >>> interested, in fact I don't want to hear any more about sharing lowlevel >>> VGA device drivers until someone addresses why it is acceptable to have >>> two separate driver driving the same hardware for video and not for >>> anything else.. (remembering graphics cards are not-multifunction >>> cards - >>> like Christoph used as an example before - 2d/3d are not separate >>> functions...)... >> >> >> We've addressed this before. Zillions of drivers provide multiple >> functions to multiple higher level subsystems. They don't all have to >> be compiled together to make it work. >> >> 2D and 3D _are_ to most intents and purposes different functions. They >> are as different as IDE CD and IDE disk if not more so. > > > Functions - yes, but they become such only at a higher level. 3d for > example does not really exist in kernel in any form. > > I would like to see unified fb (or the hardware-specific part of fb) and > drm for one simple reason that I think you mentioned: > > One driver per device. I.e. one driver per *physical* device. > > Lastly, one point that you appear to have missed: DRM does DMA transfers > (among everything else). FB sets video modes - i.e. messes with PLL. > The problem is that there are configurations where messing with PLL > while a DMA trasfer is active will lock up PCI (or AGP) bus hard. > > For example, a video decoder can be clocked off pixel clock for video > pass through mode. If we trasfer video data to main RAM at the same time > and > FB gets a command instructing it to change resolution there would be a > hard lockup.
I can see this being the case, but why can't fb just using existing drm interfaces to achieve device quiescence before touching the PLL's?
Keith - 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/
| |