* I2C parallel port adapters drivers @ 2003-11-02 12:23 Jean Delvare 2003-11-07 9:49 ` DI Dr Simon Vogl 2003-11-14 1:11 ` Greg KH 0 siblings, 2 replies; 6+ messages in thread From: Jean Delvare @ 2003-11-02 12:23 UTC (permalink / raw) To: Simon Vogl, Daniel Smolik; +Cc: Greg KH, sensors, linux-kernel Hi all, I have been playing with I2C parallel port adapters drivers for the last few days and I believe that some cleanups would be welcome. I will expose the facts as I gathered and understood them, and then do some proposals about what I think should be made. There are four different drivers that let you use the parallel port as an I2C bus. i2c-philips-par i2c-elv i2c-velleman i2c-pport The first three are already present in Linux 2.4 and have also been ported to Linux 2.6. The fourth is obviously newer (admittedly derived from i2c-velleman) and only present in i2c CVS. The last three drivers are very, very similar. Take a look at them, and you'll see that they only differ in which pins are used for the I2C bus' SCL and SDA lines. They access the parallel port directly, without using the parport module. The first one, i2c-philips-par, is different, since it relies on the parport module. That said, it is similar to the other ones in spirit, using the parallel port pins as an I2C bus. Only the access method differ. My point is that we don't need four different modules for the very same purpose. We'd better have one single module, supporting all adapter types through a parameter. The i2c-philips-par module already has such a mechanism, allowing for two different pins configuration trough its type parameter. I know have to understand why one module is using the parport module, while the other ones are bypassing it. Do we have a reason to prefer one method to the other? Using the hardware I have, I could check that both methods are working (at least for me), but I might be missing something the original modules authors had to mind when writing them. I guess that the kernel has policies about how drivers should rely on each other, I would want to learn about that. I think we should merge the four drivers into a single one, or at least (if there is one good reason to access the parallel port using two different methods) the last three drivers into a single one. I volunteer to do so, but I want to ear opinions about the idea before going on. Comments welcome (requested, even). -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: I2C parallel port adapters drivers 2003-11-02 12:23 I2C parallel port adapters drivers Jean Delvare @ 2003-11-07 9:49 ` DI Dr Simon Vogl 2003-11-07 21:36 ` Jean Delvare 2003-11-14 1:11 ` Greg KH 1 sibling, 1 reply; 6+ messages in thread From: DI Dr Simon Vogl @ 2003-11-07 9:49 UTC (permalink / raw) To: sensors, linux-kernel hi, sorry for the late answer. you're right, the drivers are very similar, and typically you will only use one of them. It is of course possible to integrate them all into one physical module, which you are free to do :) This is more or less grounded on historic reasons far back in the development of the driver where I introduced the different hardware access implementations to accomodate the different implementations (and this went eventually into the kernel...). So I'd say, go ahead and code :) Jean Delvare wrote: > Hi all, > > I have been playing with I2C parallel port adapters drivers for the last > few days and I believe that some cleanups would be welcome. I will > expose the facts as I gathered and understood them, and then do some > proposals about what I think should be made. > > There are four different drivers that let you use the parallel port as > an I2C bus. > > i2c-philips-par > i2c-elv > i2c-velleman > i2c-pport > > The first three are already present in Linux 2.4 and have also been > ported to Linux 2.6. The fourth is obviously newer (admittedly derived > from i2c-velleman) and only present in i2c CVS. > > The last three drivers are very, very similar. Take a look at them, and > you'll see that they only differ in which pins are used for the I2C bus' > SCL and SDA lines. They access the parallel port directly, without using > the parport module. > > The first one, i2c-philips-par, is different, since it relies on the > parport module. That said, it is similar to the other ones in spirit, > using the parallel port pins as an I2C bus. Only the access method > differ. > > My point is that we don't need four different modules for the very same > purpose. We'd better have one single module, supporting all adapter > types through a parameter. The i2c-philips-par module already has such a > mechanism, allowing for two different pins configuration trough its type > parameter. > > I know have to understand why one module is using the parport module, > while the other ones are bypassing it. Do we have a reason to prefer one > method to the other? Using the hardware I have, I could check that both > methods are working (at least for me), but I might be missing something > the original modules authors had to mind when writing them. I guess that > the kernel has policies about how drivers should rely on each other, I > would want to learn about that. > > I think we should merge the four drivers into a single one, or at least > (if there is one good reason to access the parallel port using two > different methods) the last three drivers into a single one. I volunteer > to do so, but I want to ear opinions about the idea before going on. > > Comments welcome (requested, even). > -- Dipl.-Ing. Dr. Simon Vogl ! http://www.voxel.at/ VoXel Interaction Design ! office@voxel.at Breitwiesergutstr. 50 ! +43 650 2323 555 A-4020 Linz - Austria ! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: I2C parallel port adapters drivers 2003-11-07 9:49 ` DI Dr Simon Vogl @ 2003-11-07 21:36 ` Jean Delvare 2003-11-09 17:38 ` Dr. Simon Vogl 0 siblings, 1 reply; 6+ messages in thread From: Jean Delvare @ 2003-11-07 21:36 UTC (permalink / raw) To: DI Dr Simon Vogl; +Cc: sensors, linux-kernel > hi, > sorry for the late answer. No problem. After all, you're the first one to answer, too ;) > you're right, the drivers are very similar, and typically you will > only use one of them. It is of course possible to integrate them all > into one physical module, which you are free to do :) This is more or > less grounded on historic reasons far back in the development of the > driver where I introduced the different hardware access > implementations to accomodate the different implementations (and this > went eventually into the kernel...). > > So I'd say, go ahead and code :) OK, I'll write a unified driver then. Just one more question. Any reason to prefer direct I/O access (ELV/Velleman) over parallel-port-style programming (i2c-philips-par)? I'd say that the second is preferable, but you might have had a reason to use direct access, that I ignore. If not, I'll somehow use i2c-philips-par as a base for my unified driver, which I'll probably call i2c-parport (since it won't be Philips-specific anymore). That driver would support Philips adapters, ELV, Velleman and ADM evaluation boards (I have one here for testing). Thanks a lot for spending some time replying. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: I2C parallel port adapters drivers 2003-11-07 21:36 ` Jean Delvare @ 2003-11-09 17:38 ` Dr. Simon Vogl 2003-11-09 21:23 ` Jean Delvare 0 siblings, 1 reply; 6+ messages in thread From: Dr. Simon Vogl @ 2003-11-09 17:38 UTC (permalink / raw) To: sensors; +Cc: DI Dr Simon Vogl, linux-kernel Jean, some comments, in no particular order :) When I wrote the parallel port drivers, the parport api was changing a lot. Therefore I did not make use of it. Blocking the parport might be a good idea, but it introduces another dependency. Anyway, parport only makes real sense when you want to share your parport between multiple devices, say a zip drive. Therefore, a question to the whole sensors list: Is anyone really using such a setup? It should be at least be configurable as an option (also think of using it in embedded devices, where you wouldn't want to bloat the kernel with such things...) Also, are there any hardware cracks out there with multiple adapters, like a home-brew philips adapter and a velleman kit on two parports? Just a few special cases to think about... As for the naming, i2c-parport would conflict with the old i2c-parport module that is still available in 2.4ish kernels in the v4l section - maybe i2c-parallel is an option. Also, have a look at the wealth of i2c drivers that are present in the 2.6 kernels :) So long, Simon Jean Delvare wrote: >OK, I'll write a unified driver then. Just one more question. Any reason >to prefer direct I/O access (ELV/Velleman) over parallel-port-style >programming (i2c-philips-par)? I'd say that the second is preferable, >but you might have had a reason to use direct access, that I ignore. If >not, I'll somehow use i2c-philips-par as a base for my unified driver, >which I'll probably call i2c-parport (since it won't be Philips-specific >anymore). That driver would support Philips adapters, ELV, Velleman and >ADM evaluation boards (I have one here for testing). > >Thanks a lot for spending some time replying. > > > -- Dipl.-Ing. Dr. Simon Vogl ! http://www.voxel.at/ VoXel Interaction Design ! office@voxel.at Breitwiesergutstr. 50 ! +43 650 2323 555 A-4020 Linz - Austria ! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: I2C parallel port adapters drivers 2003-11-09 17:38 ` Dr. Simon Vogl @ 2003-11-09 21:23 ` Jean Delvare 0 siblings, 0 replies; 6+ messages in thread From: Jean Delvare @ 2003-11-09 21:23 UTC (permalink / raw) To: Dr. Simon Vogl; +Cc: sensors, linux-kernel > When I wrote the parallel port drivers, the parport api was changing a > lot. Therefore I did not make use of it. Blocking the parport might be > a good idea, but it introduces another dependency. I guess the parport api is stable now, so there should be no problem using it. And yes, not everyone will enjoy the dependency over parport.o, especially when it's ten times bigger than the module that depends on it. Still this is the clean way of doing things, isn't it? > Anyway, parport only makes real sense when you want to share your > parport between multiple devices, say a zip drive. Therefore, a > question to the whole sensors list: Is anyone really using such a > setup? I have been, and could again for testing, but that's not my regular configuration. Mind you, it looks like parallel port is a dying technology. Most of the time it has been replaced by SCSI or USB, so having one parallel port device is quite uncommon nowadays - more than one must be really rare. That said, the parport module has more than that. It has a procfs interface, device detection, and probably workarounds for broken systems. Also, Mark D. Studebaker pointed out that using the parport module would probably help a lot on non-PC architectures over direct I/O operations. Portability is something we would like in the new driver. > It should at least be configurable as an option (also think of > using it in embedded devices, where you wouldn't want to bloat the > kernel with such things...) If an option, it would have to be a compilation time one, since I believe the dependencies are computed at compilation time. And it would make the driver even bigger anyway, were it a run time option. I wasn't thinking about that option, but you might be right, so I'll think of it. Anyway, the driver will be bigger than each of the individual drivers we had today, since it will support all known adapters. So I could also set them all as compilation time options, so that people needing support for a single adapter would only select this one. Having such a modular driver will require some more work, but it should make it suitable for everyone's specific use. Having a unified driver could also let me add a preliminary autodetection of the hardware. Providing i2c-algo-bit has been loaded with the bit_test=1 option, we could try initializing all known modes in a row, until one succeeds. Full autodetection is impossible though (some adapters have their lines inverted and we have no way to detect that). > As for the naming, i2c-parport would conflict with the old i2c-parport > module that is still available in 2.4ish kernels in the v4l section - > maybe i2c-parallel is an option. Oh, interesting. I had missed that one. So there is a fifth Linux i2c-over-parallel-port driver. Funny I missed the only one that has the right name ;) But I wouldn't have looked for such a driver in media/video, for sure. Why is it lost here? That driver would be part of my unified driver anyway, so it wouldn't hurt to keep the name, would it? (I could just pretend I am extending it ;)) > Also, have a look at the wealth of i2c drivers that are present in the > 2.6 kernels :) Not sure I get you here. What do you want me to pay attention to exactly? Thanks again Simon for the precious insightful remarks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: I2C parallel port adapters drivers 2003-11-02 12:23 I2C parallel port adapters drivers Jean Delvare 2003-11-07 9:49 ` DI Dr Simon Vogl @ 2003-11-14 1:11 ` Greg KH 1 sibling, 0 replies; 6+ messages in thread From: Greg KH @ 2003-11-14 1:11 UTC (permalink / raw) To: sensors, linux-kernel; +Cc: Simon Vogl, Daniel Smolik On Sun, Nov 02, 2003 at 01:23:42PM +0100, Jean Delvare wrote: > > I think we should merge the four drivers into a single one, or at least > (if there is one good reason to access the parallel port using two > different methods) the last three drivers into a single one. I volunteer > to do so, but I want to ear opinions about the idea before going on. Sounds like a good idea. greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-11-14 1:42 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-02 12:23 I2C parallel port adapters drivers Jean Delvare 2003-11-07 9:49 ` DI Dr Simon Vogl 2003-11-07 21:36 ` Jean Delvare 2003-11-09 17:38 ` Dr. Simon Vogl 2003-11-09 21:23 ` Jean Delvare 2003-11-14 1:11 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).