Date: Sun, 25 Dec 2016 00:22:18 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: "Constantine A. Murenin" <cnst++@FreeBSD.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> Subject: Re: superio driver Message-ID: <b39dc96b-64d4-3512-1dd2-03b0cd611f0f@FreeBSD.org> In-Reply-To: <CAPKkNb5ThwtkhRn%2Bs%2BKbvJDGbLP5BFNfmdkz1x0Ne7FaQDZO9g@mail.gmail.com> References: <eac1d53d-0b65-454d-2bf2-bdec08ffd960@FreeBSD.org> <0d588744-c83f-1f04-3c79-89cba63949a3@FreeBSD.org> <CAPKkNb5ThwtkhRn%2Bs%2BKbvJDGbLP5BFNfmdkz1x0Ne7FaQDZO9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/11/2016 00:30, Constantine A. Murenin wrote: > On 3 November 2016 at 05:16, Andriy Gapon <avg@freebsd.org> wrote: >> On 17/10/2016 11:19, Andriy Gapon wrote: >>> >>> I would like to add a driver for Super I/O chips: >>> https://reviews.freebsd.org/D8175 >>> In the review request you can find my rationale and description for the driver >>> as well as some question about its design. >>> At this point I am looking mostly for some help with the design, but any reviews >>> of the current code are also appreciated. >> >> Still looking for comments and suggestions. >> Thanks! > > I think it's an interesting idea; I've had it a few years ago in the > context of OpenBSD, but didn't pursue it further due to a lack of much > uniformity around the Super I/O chips from different vendors. > > LPC Super I/O chips from Winbond/Nuvoton and ITE do use a separate ISA > port for its Hardware Monitor functionality (often 0x290/8), and the > exact port number itself is still best be discovered through the Super > I/O driver (0x2e/2). On the other hand, the watchdog timer is > nonetheless usually implemented within the confines of the main Super > I/O logic itself (e.g., 0x2e/2). > > http://mail-index.netbsd.org/tech-kern/2010/02/17/msg007343.html > http://mdoc.su/f110/wbwd.4 Nod. > In the case of Winbond, as per above, it did result in two drivers > being there in {Net,Open,DragonFly}BSD, one for the Super I/O that > does the discovery (and which might potentially have support for the > watchdog functionality), and another for the Hardware Monitor (the > lm-compatible one, which can also attach directly on I2C in > {Net,Open}BSD): > > http://bxr.su/DragonFly/sys/dev/powermng/wbsio/wbsio.c > > http://mdoc.su/n,o,d/wbsio.4 > http://mdoc.su/n,o,d/lm.4 Nod. > However, in the case of http://mdoc.su/o/viasio.4 and > http://mdoc.su/n/itesio.4, the logic of Super I/O and Hardware Monitor > may be stuffed together into a single driver, even though both > functions are still performed at separate IO ports (look for the > multiple bus_space_map(9) calls, in fact, viasio(4) has separate ports > not only for the Hardware Monitor function, but for the Watchdog Timer > as well, something which is unique to it and is not shared by ITE and > Winbond/Nuvoton chips; nonetheless, all of these ports are claimed by > a single driver): > > http://bxr.su/OpenBSD/sys/dev/isa/viasio.c#viasio_hm_init > http://bxr.su/NetBSD/sys/dev/isa/itesio_isa.c#itesio_isa_attach I see. > If support for all of these Super IO chips would be implemented in a > single driver That's not a goal, it may or may not happen. > then FreeBSD might as well end up with its own version > of what the I2C bus scan is on OpenBSD: > > http://bxr.su/OpenBSD/sys/dev/i2c/i2c_scan.c#iic_probe_sensor I think that we would never have anything like this in FreeBSD. Poking random I2C / SMBus devices is considered too dangerous. But that's not important for this discussion. > Which is not necessarily a bad thing, and, in fact, provides an I2C > discovery interface which is very similar to what the situation is on > the more well designed platforms compared to x86, e.g., those that > have a smart property-based discovery mechanism via Open Firmware. > > However, realistically, I am not sure what will we gain in this case > of probing for all of these Super I/O chips from a single bus driver; > in fact, as you've already noticed yourself, even the probing > mechanisms are already different between ITE and Winbond/Nuvoton, so, > what exactly do we gain by having it all together in a new bus? My idea is very simple. A Super I/O chip usually implements many functions. There can be multiple drivers for the same Super I/O, each of them handling a subset of the functions. Each of the drivers may need some extra information about the Super I/O like its revision or its pin mapping configuration. So, the idea is that the code and logic that can be shared between those multiple drivers is contained in the superio driver. The drivers for individual functions attach to the superio driver and use its services. Some drivers may need those services only at the attach time to discover the version of the Super I/O and required resources (somewhat like wbsio and lm in other BSDs). Other drivers (like watchdog drivers) may continuously use those services to access the Super I/O's registers. Also, the superio driver would act as an arbiter for selecting the current LDN in this scheme. Finally, the individual drivers may have multiple attachments. E.g. a driver for a HWM function may have an isa attachment and a superio attachment (and possibly an I2C attachment). So, it would be up to a user to specify how the driver should attach. In some configurations the superio driver could be excluded at all. In others it could be used to auto-discover the Super I/O device and its configuration for the HWM component. Hope that this makes some sense. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b39dc96b-64d4-3512-1dd2-03b0cd611f0f>