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.