On Tue, 19 May 2015, Quentin Garnier wrote: > On Tue, May 19, 2015 at 12:12:17AM +0000, Taylor R Campbell wrote: >> Date: Tue, 19 May 2015 06:57:44 +0800 (PHT) >> From: Paul Goyette <[email protected]> >> >> On Mon, 18 May 2015, Masao Uebayashi wrote: >> >> > How about: >> > >> > - making pcppi(4) provide the new pcppibus(4), and >> > - making attimer(4) and pckbd(4) attach at pcppibus(4) >> >> A couple of issues with this approach: >> >> * pckbd already attaches at an unrelated parent, pckbc >> * attimer can attach currently at acpi, as well as at isa >> >> The real problem here is that these other drivers, whether they're >> children of pcppi or of something else, are optional. And their very >> presence, whether or not any instance is actually configured, (and >> without regard to where they are attached) changes the behavior of >> pcppi. >> >> Can you explain how the devices are actually related, both in the >> hardware and in the kernel representations of it, irrespective of how >> it is currently manifested in autoconf? > > IIRC, for attimer(4) and pcppi(4), they share register space. They > appear as distinct devices in ACPI trees though so it makes things > interesting.
Yes, this is correct. Additionally, even though we allow for the attimer device to attach via acpi, the bell code in pcppi.c still manipulates the timer's isabus registers directly. :( Wholesale violation of the device-tree paradigm. >> Sometimes there is a non-tree relation between two devices in a piece >> of physical hardware which both hang off a generic bus that ought not >> to have device-specific hacks to make the two talk. E.g., the HD >> audio and graphics devices on current Intel PCI buses exhibit this. > > It's even worse in the eval board world where some devices depend on > muxes or clocks being set up correctly, and those appear in very > different area of the device tree. > >> But I'm not sure a generic autoconf mechanism is warranted for such >> glue. Better to identify working solutions for specific cases and >> then generalize, rather than start with a super-generic mechanism >> before it has been demonstrated to work well in any specific case. > > I think a generic autoconf mechanism would be welcome to be able to > discover devices and walk down a firmware-provided device tree at the > same time. That would save a lot of the register_device(9) (or > whatever that API is called) magic where every time the arch-specific > code has to enumerate the device tree to find the matching device and > get information. register_device(9) == config_found_ia() perhaps > It's a rather difficult problem though. Yup. ------------------------------------------------------------------------- | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -------------------------------------------------------------------------
