Re: radeon-pre-2

Keith Whitwell
2004-09-11T08:44:06Z

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