Re: radeon-pre-2

[Jon Smirl <jonsmirl@gmail.com>]

On Sat, 11 Sep 2004 13:49:34 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> On Sat, 11 Sep 2004, Alan Cox wrote:
> 
> > On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> >> This is a good point - if we don't need DMA or 3d acceleration we can
> >> reduce memory footprint. This would seem that current DRM driver would
> >> need to be dependent on whatever driver contains the mode setting code.
> >>
> >> What do you think ?
> >
> > Jon wants to get mode setting into a seperate piece of functionality -
> > preferably in user space for many cards. I'd dearly love to see hotplug
> > handing all but some "emergency" pre-computed mode settings.
> 
> I think there is a misunderstanding.
> 
> My view was that PLL setting (and setting of a fixed mode) would be done
> in DRM driver. This way it would be able to restore previous settings
> after a lockup or respond to FB request to change modes.
> 
> However the decision of which mode to set, as well as where the
> framebuffer is located is done in user-space. (So that subtleties of
> layout of offscreen memory are not in the kernel).
> 
> Jon - did I understand you correctly ?

All register writes would occur in the driver. There is nothing
stopping the code that computes those register values from running in
user space.

A example mode setting IO would take:
  display buffer offset
  width, height, stride, etc - for fbcon to use
  register values to set the mode

Mode setting needs to be serialized. It may be better to do the
serialization before the hotplug event, in that case the mode setting
IOCTL would be implicitly serialized and not need a separate lock.

-- 
Jon Smirl
jonsmirl@gmail.com