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

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.129 / U:10.944 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site