Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)
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)
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)
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
Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)
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