| Message ID | 20210914100415.1549208-1-daniel@0x0f.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | SigmaStar SSD20XD GPIO interrupt controller | expand |
On Tue, Sep 14, 2021 at 07:04:12PM +0900, Daniel Palmer wrote: > In new SigmaStar SoCs they have moved away from having a few > interrupt capable GPIOs and instead have chained yet another > interrupt controller in to provide interrupt support for > all of the GPIOs. > > I'm hardly an IRQ expert so I expect I've made a total > mess of this. No one else was going to write this driver > so I had a go. Hi Daniel How are the GPIOs mapped to the interrupts? Is it a simple 1:1? The GPIO core has some support for the GPIO drivers to be also interrupt controllers. So if this interrupt control is dedicated to GPIO, you would be better to make it part of the GPIO driver. Andrew
Hi Andrew, On Wed, 15 Sept 2021 at 00:59, Andrew Lunn <andrew@lunn.ch> wrote: > How are the GPIOs mapped to the interrupts? Is it a simple 1:1? Unfortunately, no. I wanted to add the GPIO controller part of this to this same series but there are some patches in flight for that so it would have been messy. You can see that here though: https://github.com/linux-chenxing/linux/commit/88345dc470bf07d36aa1ddab09551ed33a1cfb22 They've really made a mess of this. Their whole GPIO thing is a mess with no clear logic between the pin names and the register locations etc. This IRQ part is no exception. IRQ 0 from this thing isn't for the pin called GPIO0 or anything sane like that. > The GPIO core has some support for the GPIO drivers to be also > interrupt controllers. So if this interrupt control is dedicated to > GPIO, you would be better to make it part of the GPIO driver. I don't think so. One reason is the non-linear mapping stuff. A second reason is this GPIO interrupt controller might handle GPIO interrupts for multiple GPIO controller blocks. Finally, in newer chips they've replaced one of the GPIO blocks with a new IP which will need it's own driver. That GPIO controller still seems to use this same IRQ block to handle it's interrupts. So if this code is wrapped into the GPIO driver itself it would end up duplicated in two GPIO drivers. Cheers, Daniel
On Wed, Sep 15, 2021 at 06:06:52PM +0900, Daniel Palmer wrote: > Hi Andrew, > > On Wed, 15 Sept 2021 at 00:59, Andrew Lunn <andrew@lunn.ch> wrote: > > How are the GPIOs mapped to the interrupts? Is it a simple 1:1? > > Unfortunately, no. > I wanted to add the GPIO controller part of this to this same series > but there are some patches in flight for that so it would have been > messy. > You can see that here though: > https://github.com/linux-chenxing/linux/commit/88345dc470bf07d36aa1ddab09551ed33a1cfb22 > > They've really made a mess of this. Their whole GPIO thing is a mess > with no clear logic between the pin names and the register locations > etc. > This IRQ part is no exception. IRQ 0 from this thing isn't for the pin > called GPIO0 or anything sane like that. O.K. Then it sounds like splitting GPIO and the IRQ makes sense. This is the sort of thing which is good to put in the cover letter, explaining why you decided to do it this way. Andrew
Hi Andrew, On Thu, 16 Sept 2021 at 05:34, Andrew Lunn <andrew@lunn.ch> wrote: > O.K. Then it sounds like splitting GPIO and the IRQ makes sense. This > is the sort of thing which is good to put in the cover letter, > explaining why you decided to do it this way. Good point. I'll probably need to send a v2 at some point so I'll add it to the cover letter then. I have a working driver for the other GPIO IP block that uses this interrupt controller now so I can link that too. Thanks, Daniel