Date: Mon, 25 Jul 2016 09:48:24 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Michal Meloun <mmel@freebsd.org>, Svatopluk Kraus <skra@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: INTRNG (Was: svn commit: r301453....) Message-ID: <f94bfd25-fabf-efc3-55c9-cfdfd9e4d6e6@freebsd.org> In-Reply-To: <CANCZdfr%2BZ4XxXRY0yMiWXwp=8iKq54y3uJ9-OfAOdfxAs1qdtw@mail.gmail.com> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <b9606755-69cb-2cb0-04d7-6be32e4cb89e@freebsd.org> <578E0B5D.3070105@FreeBSD.org> <e026f6fc-76ed-5dbe-00fc-365b6d7bcf94@freebsd.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <f82018ee-51e7-60fa-2682-f0ef307a52b5@freebsd.org> <57961549.4020105@FreeBSD.org> <e2cace17-0924-2084-5fcf-626f87e41cc3@freebsd.org> <CANCZdfr%2BZ4XxXRY0yMiWXwp=8iKq54y3uJ9-OfAOdfxAs1qdtw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/25/16 09:32, Warner Losh wrote:
> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn
> <nwhitehorn@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@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@f0008000 {
> pinctrl-0 = <
> &pinctrl_board_mmc0
> &pinctrl_mmc0_slot0_clk_cmd_dat0
> &pinctrl_mmc0_slot0_dat1_3>;
> status = "okay";
> slot@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
>
Where we would run into (minor) problems is if the interrupt parent for
the first mmc0 is the GPIO controller. More generally, if &pioD has
interrupt children specified in some way that is not a <pin, active
high/whatever> tuple somewhere else in the tree then you would have to
have methods to parse both interrupt specifiers
as-obtained-from-interrupts-properties (or equivalent) and specifiers
as-obtained-from-gpio-properties. If the tree picks one format and
sticks with it, you can get away with just the one. Glancing through the
DTS source for this board, that doesn't appear to be the case and the
property formatting is uniform, but I might have missed something in one
of the many #includes.
As a general point, GPIO weirdness would be easy enough case to handle
if it did come up (add some mapping method, as above) that I think we
shouldn't worry too much about it from an architectural point of view.
If a board appears that is set up this way, we can roll with the punches
at that point and add whatever small amount of shim code that is
required. It would be annoyance, sure, but not a real complication.
-Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f94bfd25-fabf-efc3-55c9-cfdfd9e4d6e6>