| Message ID | cover.1521723192.git.vilhelm.gray@gmail.com |
|---|---|
| Headers | show |
| Series | Implement get_multiple for ACCES and PC/104 drivers | expand |
On Thu, Mar 22, 2018 at 1:59 PM, William Breathitt Gray <vilhelm.gray@gmail.com> wrote: > Changes in v4: I applied the v4 patch set so we get some rotation in linux-next before the merge window. If reviewers still find smallish issues they can certainly be fixed in follow-up patches. > This patchset implements get_multiple callbacks for the PC104 GPIO > drivers as well as the PCI-IDIO-16 and PCIe-IDIO-24 GPIO drivers. These > devices all acquire the multiple input lines with a single read, so > utilizing the get_multiple callback can provide improvement for those > users who regularly access multiple input lines. Did you use the userspace chardev for some interesting experiments with your set-ups? I tend to think of your applications as pretty interesting for industry peers, and a good proof-of-concept for the userspace API. > While developing this patchset I noticed many of these devices make use > of Intel 8255 compatible interfaces for their I/O. I may write a generic > 8255 GPIO driver in the future to reduce some of the redundant code I > see pop among the drivers for these devices. Oh! This guy? https://en.wikipedia.org/wiki/Intel_8255 Yeah that makes all kind of sense. We are living with the legacy of the first PCs every day when it comes own to EISA & friends... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 26, 2018 at 10:31:41AM +0200, Linus Walleij wrote: >On Thu, Mar 22, 2018 at 1:59 PM, William Breathitt Gray ><vilhelm.gray@gmail.com> wrote: > >> Changes in v4: > >I applied the v4 patch set so we get some rotation in linux-next before >the merge window. > >If reviewers still find smallish issues they can certainly be fixed in follow-up >patches. > >> This patchset implements get_multiple callbacks for the PC104 GPIO >> drivers as well as the PCI-IDIO-16 and PCIe-IDIO-24 GPIO drivers. These >> devices all acquire the multiple input lines with a single read, so >> utilizing the get_multiple callback can provide improvement for those >> users who regularly access multiple input lines. > >Did you use the userspace chardev for some interesting experiments >with your set-ups? > >I tend to think of your applications as pretty interesting for industry >peers, and a good proof-of-concept for the userspace API. I use these PC104 drivers in several semi-realtime critical applications, so latency has always been a big concern for me. The switch from sysfs file I/O to chardev ioctl had a great improvement in the reduction of latency, which I was very happy to utilize. Since the next big point of latency in my systems have been port I/O, taking advantage of the get_multiple/set_multiple functionality is my next goal in optimization. I have a new system coming out soon that uses the 104-IDI-48 for input -- it'll be interesting to see the performance improvements of acquiring the entire input port at a time, rather than every GPIO line individually. > >> While developing this patchset I noticed many of these devices make use >> of Intel 8255 compatible interfaces for their I/O. I may write a generic >> 8255 GPIO driver in the future to reduce some of the redundant code I >> see pop among the drivers for these devices. > >Oh! >This guy? >https://en.wikipedia.org/wiki/Intel_8255 > >Yeah that makes all kind of sense. We are living with the legacy >of the first PCs every day when it comes own to EISA & friends... That's the one! I see this interface a lot in the GPIO devices I handle. It's very popular, which I believe is a testament to the popularity of the IBM PC. Nowadays, most devices I encounter implement this interface in an FPGA, but I do occasionally come across the actual Intel 82C55 chip, such as on the 104-DIO-48E; it's fascinating to see this physical chip still popping up on circuit boards from time to time. I would like to make a generic driver for this interface that will allow it to be used both in the port I/O and memory I/O drivers out there. Since I don't want to introduce too many changes in a single patchset I've postponed it for now to get get_multiple support merged in for these drivers, but I'll hopefully have something like a gpio-i8255 driver submitted soon enough. William Breathitt Gray > >Yours, >Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html