lkml.org 
[lkml]   [2003]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Multiple drivers for same hardware:, was: DRM and pci_driver conversion

> Since they have to co-operate some way on the resources _anyway_, they'll
> just need to work it out amongst themselves.
>
> One common case is to have a "arbitration driver" that tends to do the
> actual low-level accesses and is one level of abstraction over the
> hardware (papers over trivial differences in hardware). An example of this
> would be the old-style ISA DMA infrastructure (now happily pretty much
> dead), where the "DMA driver" was just a trivial layer that had some basic
> allocation/deallocation and had somewhat nicer access routines than the
> raw IO accesses, but didn't do much more.

I already have thought ahead about this issue. That is why one of the
major changes to the framebuffer layer was to seperate the driver data
into struct fb_info and a struct xxx_par. The idea was the data in struct
fb_info was for the framebuffer layer and the data in struct xxx_par could
be shared with other interfaces like DRI. The par idea can be extended
further and we could use a common structure between a low level text mode
console driver and a graphics driver. For example mdacon and hgafb.



-
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 13:58    [W:0.043 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site