From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: "rayagonda.kokatanur@broadcom.com"
<rayagonda.kokatanur@broadcom.com>,
"bcm-kernel-feedback-list@broadcom.com"
<bcm-kernel-feedback-list@broadcom.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"li.jin@broadcom.com" <li.jin@broadcom.com>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"sbranden@broadcom.com" <sbranden@broadcom.com>,
"rjui@broadcom.com" <rjui@broadcom.com>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)
Date: Tue, 1 Oct 2019 03:04:36 +0000 [thread overview]
Message-ID: <f3a243b1f22cf29075467d236610dbd2e7a20e55.camel@alliedtelesis.co.nz> (raw)
In-Reply-To: <d72a965a-e4e1-ba5d-cd62-b31939e75e44@gmail.com>
Hi Florian,
On Mon, 2019-09-30 at 19:54 -0700, Florian Fainelli wrote:
>
> On 9/30/2019 7:33 PM, Chris Packham wrote:
> > Hi,
> >
> > We have a platform using the BCM53344 integrated switch/CPU. This is
> > part of the Hurricane 2 (technically Wolfhound) family of devices.
> >
> > Currently we're using pieces of Broadcom's "iProc" SDK based on an out
> > of date kernel and we'd very much like to be running as close to
> > upstream as possible. The fact that the Ubiquiti UniFi Switch 8 is
> > upstream gives me some hope.
>
> FYI, I could not get enough information from the iProc SDK to port (or
> not) the clock driver, so if nothing else, that is an area that may
> require immediate work (though sometimes fixed-clocks would do just fine).
Setting a fixed clock seems to work for me. At least for now.
>
> >
> > My current problem is the fact that the uart0 interrupt is shared with
> > the Chip Common A gpio block. When I have and interrupt node on the
> > gpio in the device tree I get an init exit at startup. If I remove the
> > interrupt node the system will boot (except I don't get cascaded
> > interrupts from the GPIOs).
> >
> > Looking at the pinctrl-nsp-gpio.c it looks as though I might be able to
> > make this work if I can convince the gpio code to return IRQ_HANDLED or
> > IRQ_NONE but I'm struggling against the fact that the pinctrl-iproc-
> > gpio.c defers it's interrupt handing to the gpio core.
>
> Not sure I follow you here, what part is being handed to gpiolib? The
> top interrupt handler under nsp_gpio_irq_handler() will try to do
> exactly as you described. In fact, there are other iProc designs where
> "gpio-a" and another interrupt, arch/arm/boot/dts/bcm-nsp.dtsi is one
> such example and I never had problems with that part of NSP.
>
nsp_gpio_probe() creates the irq domain directly and
nsp_gpio_irq_handler() directly deals with sharing by returning
IRQ_HANDLED or IRQ_NONE depending on whether it has a bit set.
iproc_gpio_probe() on the sets iproc_gpio_irq_handler() as the
parent_handler and defers to gpiolib to deal with the irq domain etc.
I'm currently assuming this is why I can't have uart0 and gpio
interrupts. But of course I could be completely wrong.
> >
> > Is there any way I can get the gpio core to deal with the shared
> > interrupt?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-01 3:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 2:33 Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc) Chris Packham
2019-10-01 2:54 ` Florian Fainelli
2019-10-01 3:04 ` Chris Packham [this message]
2019-10-02 21:15 ` Chris Packham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f3a243b1f22cf29075467d236610dbd2e7a20e55.camel@alliedtelesis.co.nz \
--to=chris.packham@alliedtelesis.co.nz \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=li.jin@broadcom.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rayagonda.kokatanur@broadcom.com \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).