New DRM model

[Jon Smirl]

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I'm talking about the part of the code blasting the card registers. The
> mode setting cannot be completely general purpose anyway. The choice of
> a mode depends on things that can be quite specific to a given card,
> like memory organisation, common ratio for mirroring, etc...

I was going to write an IOCTL for actually setting the mode into the card but
I'm not that far along yet.  There are a bunch of other places where the Xfree
driver touches the Radeon registers; I'm slowing working through them. So far I
have fixed VBIOS reset, reading the VBIOS, I2C, getting the PCI ID, mem size,
register locations, plus everything DRM already did. I'm not far along enough
yet to know if is is reasonable for the user space library to not touch the
registers directly.

> So far, the idea we discussed with Keith would be to have a userland
> library independent on the xserver proper providing the mode setting
> "API", allowing to query the various cards & heads capabilities,
> triggering new probes, and changing the configuration. It would also
> deal with the overall display geometry (where each screen is located
> relative to the next one).

I haven't seen these discussions but I'm on the same page here. I just want to
extend use of this library to replace the VC/TTY/FB subsystem too. That way
there will only be a single library that touches the hardware.

> But the actual _implementation_ of this library has to use some per-card
> knowledge at 2 stages: Upon a user mode setting request, to decide what
> effective mode can/will be used, and that can affect the "other" card's
> head as well (like when enabling mirroring with an external 4:3 display,
> the internal non-4:3 flat panel may be resized to a 4:3 ratio).

Sounds good to me, I wasn't that far along yet.

> And then, once the full configuration for the card is decided, the
> actual blasting of registers, which should be done by the kernel for
> security reasons. (Or a trusted root process, but I'd prefer avoiding
> yet another daemon).
>  
> > Does your hardware power on to a visible configuration? If so why can't we
> use
> > that until early user-space starts? If not, the DRM driver could be
> hardwired to
> > start the card out in 640x480 until early user-space starts.
> > 
> > Note that the new model only applies to DRM devices. Everthing else would
> > continue with the old code.
> 
> Which is wrong. We are looking into a model replacing everything at this
> point, simpler and saner if possible, and designed around the DRI needs,
> for sure, but not limited to it.

No reason what I'm working on can be extended to all cards, I was just starting
with a small set of harware initially.

> Ben.
> 
> 


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html