Date: Thu, 19 Jun 2014 17:21:59 +0200 (CEST) From: Emeric POUPON <emeric.poupon@arkoon-netasq.com> To: freebsd-arch@freebsd.org Subject: Re: How to properly handle several fonctions provided by the Winbond SuperIO chip? Message-ID: <750618593.166408.1403191319583.JavaMail.zimbra@arkoon-netasq.com> In-Reply-To: <201406190919.04443.jhb@freebsd.org> References: <1118241087.138096.1403180509132.JavaMail.zimbra@arkoon-netasq.com> <201406190919.04443.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your answer! I was thinking about calling some parent device functions from the children= devices in order to perform IO accesses. But I imagine it would be "better" to expose a kind of bus interface from t= he main driver? However, I'm not sure the extra work induced is worth it. What do you think= ? Emeric Poupon ----- Mail original ----- De: "John Baldwin" <jhb@freebsd.org> =C3=80: freebsd-arch@freebsd.org Cc: "Emeric POUPON" <emeric.poupon@arkoon-netasq.com> Envoy=C3=A9: Jeudi 19 Juin 2014 15:19:04 Objet: Re: How to properly handle several fonctions provided by the Winbond= SuperIO chip? On Thursday, June 19, 2014 8:21:49 am Emeric POUPON wrote: > Hello, >=20 > I have a design question about how to configure/control a Winbond Super I= O device. >=20 > Currently, only the Watchdog feature is properly handled in FreeBSD (see = dev/wbwd), but I would like to control the GPIO that are managed by this Su= perIO device. >=20 > Making a complete separate isa driver seems not to be a good idea : > - duplicated probe/attach routines. > - concurrency accesses on the registers. Indeed this device provides an "= extended mode" in order to be configured, and it also provides a "logical d= evice"=20 selection in order to access specific features (one logical device for the = watchdog, another one for a GPIO port, etc.). >=20 > As far as I understand, they solved the problem on Linux by : > - using separate drivers > - using a memory locked mechanism when entering/exiting the extended mode= . >=20 > However, on FreeBSD I would split the whole thing in three drivers: > - wbsio (sio stands for SuperIO), the main driver: > - identify/attach/probe routines on the isa bus. > - provide primitives to enter/exit the extended mode, and hangle an int= ernal mutex to give exclusive access on this mode. > - provide primitives to select the logical device and read/write the in= ternal registers > - attach child devices "wbwd" and "gpio". > - wbwd,=20 > - child of wbsio > - register the watchdog event callback > - use wbsio primitives to get the work done > - wbgpio, > - child of wbsio > - implement gpio methods > - add child devices "gpioc" and "gpiobus" > - use wbsio primitives to get the work done >=20 > What do you think? Is that the good way to proceed? This sounds correct to treat the raw device as a bus and the logical device= s it provides as children. --=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?750618593.166408.1403191319583.JavaMail.zimbra>