Date: Wed, 3 Apr 2013 14:50:17 -0500 From: Brooks Davis <brooks@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 227289 for review Message-ID: <20130403195017.GB97453@lor.one-eyed-alien.net> In-Reply-To: <201304031512.44463.jhb@freebsd.org> References: <201304012009.r31K9NA6027721@skunkworks.freebsd.org> <201304031512.44463.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 03, 2013 at 03:12:44PM -0400, John Baldwin wrote: > On Monday, April 01, 2013 4:09:23 pm Brooks Davis wrote: > > http://p4web.freebsd.org/@@227289?ac=3D10 > >=20 > > Change 227289 by brooks@brooks_zenith on 2013/04/01 20:08:35 > >=20 > > Record the interrupt-parent of devices that have one in > > struct device. Use this to improve reporting of interrupt-parents > > in two ways: > > =09 > > Add an indication of the interrupt-parent when printing the > > child's resources: > > =09 > > altera_jtag_uart0: <Altera JTAG UART> mem 0x900000007f000000-0x9000000= 07f00003f irq 0 (beripic0) on simplebus0 > > =09 > > Extend struct u_device and the hw.bus.devices sysctl used > > by libdevinfo to include the device parent. This is done > > in a fully foward and backward compatible manner. The > > kernel can now return a partial structure when an old > > libdevinfo requests a u_device that is shorter than the > > current version. Each new field or set of fields in > > u_device is indicated by a bit in the dv_fields entry. > > =09 > > Use this new functionality to add a -i option to devinfo > > that shows the device tree by interrupt-parent rather than > > bus. Resources described as "Interrupt" are always shown > > in -i mode >=20 > Hmm, is this really generically useful? I would rather think that you mi= ght > want to export more information about interrupt sources that maps IRQ coo= kies > to (pic, pin) tuples or the like. This seems like a very platform-specif= ic > thing to be putting into 'struct device'. My thought was that interrupt parents are a fundamental concept for systems described by FDT so it was fairly generic, if not universal. It would definitely be better if information about the mapping was available, but I've not really thought of a good way to do that (at least in part because even after writing a PIC driver I still don't feel like I've got my head around the whole of our interrupt code.) As background, I've taken a non-standard approach with our pic in that it attaches to the bus and allocates interrupts from its parent. It currently installs an event handler for each child interrupt that includes a filter and handler. The filter that increments the per-source counter and calls the child's filter if there is one (it will soon do it's own filtering based on the PIC's interrupt present bit, but I've not implemented that quite yet). The event handler just calls the child's event handler. The reason for this approach vs the traditional approach of teaching nexus about each PIC is that this felt like a better abstraction for both how FDT describes interrupts and the way our PIC works. As a side benefit beri_pic knows nothing about MIPS (except in the interrupt counter code) which is relevant in that you could hook it up to a soft-core arm CPU fairly easily. -- Brooks --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRXIf4XY6L6fI4GtQRAie+AKDdlfXCkwOxj1tPyj4gYv2uFZEQfwCfeHLC 71Mwj8hns/nVZb0KiTHxeKI= =avXI -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130403195017.GB97453>