INTRNG (Was: svn commit: r301453....)
Warner Losh
imp at bsdimp.com
Mon Jul 25 16:32:26 UTC 2016
On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn
<nwhitehorn at freebsd.org> wrote:
> That wasn't my question. Are these particular device drivers allocating
> interrupts both on the GPIOs in their "interrupts" property (which are
> entirely GPIOs in this example) *and* on the GPIOs listed as resources but
> not listed as interrupts? If they are, then you need a switching mechanism,
> but that seems pretty unlikely given the names of the non-interrupt GPIOs
> (they look like outputs). It would also be a somewhat deranged way to set up
> a device tree -- not that that rules it out or anything.
On Atmel, there's a situation that this covers, I think.
The MCI device has an interrupt in the core:
mmc0: mmc at fffa8000 {
compatible = "atmel,hsmci";
reg = <0xfffa8000 0x600>;
interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
clocks = <&mci0_clk>;
clock-names = "mci_clk";
status = "disabled";
};
and in other places wires in GPIO interrupts for things like card
eject / insertion.
mmc0: mmc at f0008000 {
pinctrl-0 = <
&pinctrl_board_mmc0
&pinctrl_mmc0_slot0_clk_cmd_dat0
&pinctrl_mmc0_slot0_dat1_3>;
status = "okay";
slot at 0 {
reg = <0>;
bus-width = <4>;
cd-gpios = <&pioD 15 GPIO_ACTIVE_HIGH>;
};
};
an interrupt is registered on the cd-gpios pin for when the card changes. At
least in linux, FreeBSD doesn't (yet) implement this, but will someday if I get
back to the armv6 atmel work I started (see at91-cosino.dts for example, there's
others).
I think this is an example of what you are asking about, or did I get
lost in the
twisty maze of conversation zigs and zags...
Warner
More information about the freebsd-arch
mailing list