Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline.  DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stealth where it uses the resources without
> telling the kernel. Stealth/primary mode is a transition tool until
> things get fixed. Once everything is sorted out stealth mode can be
> removed.

I _think_ Alan's argument is that this isn't about the resource 
reservation conflicts. In many ways resource reservations don't much
matter, since for PCI devices the kernel can (and does) make sure that 
nobody else stomps on that particular IO range anyway.

So to some degree the real issue is not so much about who "owns" the 
device: clearly nobody _can_ "own" it, as there are multiple drivers that 
do want to access it. So the real issue is about how to serialize the 
existing multiple "owners".

At least this is where I _think_ Alan is coming from. You're been an 
argumentative bunch, it's hard to tell in between all the flamage ;)

> Think of this as having the shared resource platform code in the DRM
> driver. This shared platform knows how to load DRM. The next step is
> to teach it how to load fbcon. Final step is to integrate the chip
> specific code from DRM and fbdev.

Again, I think you're thinking about the problem from two fundamentally 
different standpoints. 

Jon, you want to get to that "Final step is to integrate the chip specific
code from DRM and fbdev". Alan doesn't even want to get there. I think 
Alan just wants some simple infrastructure to let everybody play together.

(Hey, at this point everybody will jump at me and tell me I'm taking
lessons from Hans, and that I'm totally misrepresenting what people want.  
"Bring it on", as those stupid US politicians would say).

So look at this another way: maybe we do _not_ want to integrate any code. 
It's ok to have fbdev/fbcon/X/DRM all sharing the same device. The only 
thing we need is something to serialize the damn things with.

My personal preference for this whole mess has always been the "silly 
driver" that isn't even hardware-specific, and really does _nothing_ on 
its own. This one would be the only thing that actually reserves the IO 
regions and "owns" the card from the respect of the resources. EVERYBODY 
else would be a "stealth" driver. Not just DRM.

And the drivers would never become non-stealth. They'd stay as stealth 
drivers, and just use the silly hardware-independent thing as a way to 
serialize themselves.

So what does the hw-independent thing need to do?

 - locking. This is the first-order problem, and maybe it never even needs 
   to go beyond this stage. If DRM can say "I want to own the 
   accelerator", and others will wait for it, then that's already a big 
   step forward.

   Implementation: have a data structure with <n> different pointers to
   locks, for each independent function you can think of that somebody
   would want exclusive access over. "accelerator" "modeswitch" 
   "framebuffer" "memory alloc" whatever.

   Now, the reason why these things are _pointers_ to locks rather than 
   locks themselves is that maybe some hardware ends up sharing resources 
   between these things (maybe "modeswitch" needs the accelerator to 
   work), and then they have to use the same lock. Fine - just make the
   pointer point to that lock. The hardware-independent part doesn't even 
   need to _know_ about this: it just sets up all <n> locks as being
   independent, and then the low-level drivers can move the lock pointers 
   around since _they_ know what the rules are.

   Or something like this.

 - memory allocation. Many of these issues really are generic, and once 
   you have the locking setup done, maybe you can have a generic memory
   allocation layer for splitting up AGP memory or whatever. See the 
   "dma_declare_coherent_memory()" interfaces that James Bottomley did for 
   some SCSI devices that have on-board memory that they want to let the 
   kernel allocate as DMA'able.

   In fact, maybe the existing _general_ dma_declare_coherent_memory() 
   interfaces can be enhanced enough that the drivers can just use that
   directly. See Documentation/DMA-API.txt for some docs (it's very 
   limited right now, because nobody _needs_ any more, but it already has 
   support for "if you can't find memory directly on the card, allocate
   some from system RAM instead" kind of operations).

Anyway, please stop the flamage. It all sounds like you're arguing across 
each other. Now you can flame me instead, but please try to direct the 
flamage to specific points so that I don't get the feeling that you're 
talking about something else..

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