Hello,
I have some questions concerning the design of a
kernel-driver.
First of all the background of the story:
I have written a driver-package for video-hardware
that is based on the SAA7146-chipset by
Philips Semiconductors. The driver can
be found at http://www.mihu.de/linux/
The package includes a driver for a tv-card
called "MXB", too.
There is something special about the SAA7146 that
cleary separates it from chipsets like the BT848:
The SAA7146 can be used in a more generic fashion.
It features input- and output-ports rather than
simple connectors for external video-sources. It
features two busses (i2c and DEBI) that can be
used to control external hardware. Because of that,
SAA7146-based hardware can differ very much and
it is impossible to write a generic driver for
all the hardware out there.
Until now, the driver can only be compiled as a
module. I'd like to incorporate it in the kernel
and so it must become very more -- well -- suitable.
Please donīt get me wrong: the driver itself is
very stable and useful, but the integration into
the kernel-environment is quite terrible at the
moment.
There is a "saa7146-core"-module, which works like
this:
When the module is inserted, it scans the pci-bus
for any available SAA7146 and allocates various
things like irqs, memory for grabbing-buffers, etc.
for all of the SAA7146 in the system.
The module then exports some functions to provide
the functionality to any "real" hardware-specific
device-driver:
EXPORT_SYMBOL(saa7146_get_handle);
EXPORT_SYMBOL(saa7146_command);
All "real" functionality lies under the "saa7146_command",
which can be called with a handle obtained by "saa7146_get_handle".
An example: lets assume that I have inserted the
"saa7146-core.o"-module and then insert my "mxb.o"-module.
The "init_function" of the module then calls "saa7146_get_handle"
as often as it returns different handles and then checks
if a MXB is present. Of course this does not work very well, when
I have different SAA7146-based hardware in my system and I want
to insert different drivers.
You should get the idea of how it works.
The good thing of this architecture is, that the real
hardware-driver does not have to worry about stuff like
irq-allocation, memory-allocation and similar at all.
It can implement an interface to a higher API like
video4linux and use the functions exported by the core-driver.
So the drivers for different hardwares do not have to
include the same code over and over again.
Ok, now I'd like to integrate the driver properly into the
kernel and I can think of only one real solution of the problem:
The core-modules gets some real locking/unlocking mechanisms with
real handle-handling. External drivers must attach and detach to
the core in order to be able to call the functions. If they want
to probe for a specific hardware for example, they have to attach,
then call some probing-functions and have to detach if the hardware
does not fit.
There is a second way in my mind, but I don't think that it is
as stable as the above one:
The core-module "knows" about all SAA7146-based hardware out there.
I think any hardware can be determined by a specific combination
of helper-chipsets sitting on the two busses, but I am not completely
sure about that. Then the core-driver can probe for the devices and
select the one that fits best...
I had a look through various kernel-drivers, but I did not find
anything that uses a mechanism like a described above. So I
am a little confused on how to actually design my driver.
I would really appreciate it, if you comment on my design I
suggested above. I am interested in any other documents dealing
withthis issue, too.
Thanks,
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:09 EST