[lkml]   [2003]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: I2C parallel port adapters drivers

    > 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

    Thanks again Simon for the precious insightful remarks.

    Jean Delvare
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.024 / U:118.788 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site