Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

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.

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.

Is there any way I can get the gpio core to deal with the shared
interrupt?

Thanks,
Chris

Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

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.

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.

Is there any way I can get the gpio core to deal with the shared
interrupt?

Thanks,
Chris
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Florian Fainelli]

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).

> 
> 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.

> 
> Is there any way I can get the gpio core to deal with the shared
> interrupt?
-- 
Florian

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Florian Fainelli]

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).

> 
> 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.

> 
> Is there any way I can get the gpio core to deal with the shared
> interrupt?
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

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?

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

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

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

On Tue, 2019-10-01 at 16:04 +1300, Chris Packham wrote:
> 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?

I think at least part of my problem is that the iProc ChipCommonB
register layout is different to the iProc ChipCommonA. It's closer to
the NorthStar Plus but still different layout. I think I'll need to
write a new driver rather than trying to get pinctrl-nsp-gpio.c or
pinctrl-iproc-gpio.c to work.

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

On Tue, 2019-10-01 at 16:04 +1300, Chris Packham wrote:
> 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?

I think at least part of my problem is that the iProc ChipCommonB
register layout is different to the iProc ChipCommonA. It's closer to
the NorthStar Plus but still different layout. I think I'll need to
write a new driver rather than trying to get pinctrl-nsp-gpio.c or
pinctrl-iproc-gpio.c to work.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel