From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Krystian Lewandowski In-Reply-To: Date: Tue, 31 Dec 2013 23:57:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54A95F7A-CCA3-42EA-AAFD-08C9B01E9F10@gmail.com> References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> <821cb256954ce0bf4ad389ffe5eafa50@mikro> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: aa5fee80-ead8-11e9-9d60-3106f5b1d025 Wiadomo=C5=9B=C4=87 napisana przez erik quanstrom = w dniu 31 gru 2013, o godz. 20:50: > On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote: >=20 >> Erik, >>=20 >> Just for the purposes of edification (and curiosity), are you able to >> elaborate on "long reads"? Its understandable such a scheme would be >> implemented in the network drivers, but how exactly does it work, as >> opposed to a polling scheme or an ISR? I will, of course, Google in a = sec >> as well. >=20 > it could be that i misunderstood the op's point. what i understood = from the > original post was a scheme was envisioned where a user process would = poll a > status file to get interrupt status. if i understood this correctly, = then providing > an interrupt file that returns even 0 bytes when there's an interrupt = would be > an alternative providing interrupt semantics to the up. there are = some=20 > bits to work out if the user process falls behind, but it's no = different than a > network device. >=20 > does that answer your question? >=20 > - erik >=20 I=E2=80=99ll answer at the bottom, to not make even more mess i did = before. :) I=E2=80=99m not even sure what is my point of view. For ISR i was = thinking about an interrupt routine writing something (a single byte) to = a file when an interrupt occurs - writing using functions defined in qio = - something similar to /dev/kprint - reading user process is waiting for = new data if i understood the behavior correctly. It is not clear to me = how this =E2=80=9E0 bytes=E2=80=9D method: > providing > an interrupt file that returns even 0 bytes when there's an interrupt = would be > an alternative providing interrupt semantics to the up could be implemented and how ioproc is related (how ioread can be woken = up with 0 bytes returned). But now, my mind isn=E2=80=99t quite clear = now. As i said i don=E2=80=99t know much about BCM, Plan 9 and the whole = thing and basic GPIO implementation seemed to be a good entry point. Now = i=E2=80=99m trying to figure out how it can be extended in the future, = regarding your feedback. But if you think it is worth to extend this = thread with new information then that would be great. Thanks for this discussion! Krystian=