From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 1 Jan 2014 17:16:35 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: ab10414a-ead8-11e9-9d60-3106f5b1d025 On Tue Dec 31 12:47:30 EST 2013, krystian.lew@gmail.com wrote: > Thank you for the feedback, > i think "ctl" file and numbering scheme selection could do the job. And= maybe it could help to establish reasonable base for SPI and others. >=20 > Is it safe to just generate new dev tree - to return either BCM, Wiring= Pi or board pin set - based on pin numbering scheme selection made by use= r? What will happen if a process would try o read/write from/to pin when = numbering scheme is changed? I tried to look at devproc.c (what would hap= pen when process dies and something is reading its /proc entries) but i c= an=E2=80=99t see any specific precautions there. >=20 > I=E2=80=99m trying to learn something - including BCM and Plan 9, i don= =E2=80=99t feel very confident. But this Plan 9 BCM port really deserves = more attention. :) I appreciate any help or feedback. >=20 > Regarding ISRs - this is not implemented yet. Polling at the moment is = the only option. But maybe "events=E2=80=9D file, with data populated by = interrupt routine would be the answer. Is it correct Plan 9 way of doing = things? QIO looks very suitable for this purpose. >=20 > I tried to look at 9front BCM tree, it seems to be a bit different (no = fakertc device for example) from the one at Bell Labs, is it by purpose o= r just trees are not synched? I=E2=80=99m asking because i have 9front on= my laptop and i=E2=80=99d like to build BCM kernel there, and so i thoug= ht maybe i could use 9pi from 9front image instead, but i=E2=80=99d like = to know what is the status. >=20 > Thank you, > Krystian >=20 > Wiadomo=C5=9B=C4=87 napisana przez California Electric w dniu 30 gru 2013, o godz. 02:47: the problem with the encoding of this email has been fixed. iso-2022-jp-= 2 should now be properly recognized. /n/atom/patch/tcs2022-jp-2 there are several further extensions which mostly embed multibyte charact= ers, but=20 i'm ignoring them for now. - erik