Re: radeon-pre-2

[Vladimir Dergachev]

> > > > 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?

Video decoder is not part of 3d engine. In fact if we are not transferring 
data via DMA into system RAM the video decoder will be running 
continuously and none of currently examined for quiescence flags would 
show it.

To do all this properly there should be a piece of code that knows all 
about currrent state of the card - which clocks are connected to what, 
which transfers are running and which parts of the engine are busy.

Btw, it would also be nice if that code received interrupts that can occur 
when user hotplugs monitors.

                             best

                                Vladimir Dergachev

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