How to properly handle several fonctions provided by the Winbond SuperIO chip?
Emeric POUPON
emeric.poupon at arkoon-netasq.com
Thu Jun 19 15:22:03 UTC 2014
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 the 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 at freebsd.org>
À: freebsd-arch at freebsd.org
Cc: "Emeric POUPON" <emeric.poupon at arkoon-netasq.com>
Envoyé: 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,
>
> I have a design question about how to configure/control a Winbond Super IO device.
>
> 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 SuperIO device.
>
> 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 device"
selection in order to access specific features (one logical device for the watchdog, another one for a GPIO port, etc.).
>
> 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.
>
> 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 internal mutex to give exclusive access on this mode.
> - provide primitives to select the logical device and read/write the internal registers
> - attach child devices "wbwd" and "gpio".
> - wbwd,
> - 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
>
> 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 devices
it provides as children.
--
John Baldwin
More information about the freebsd-arch
mailing list