On 11/04/2016 09:28 AM, Linus Walleij wrote: > On Thu, Oct 27, 2016 at 10:07 AM, Keerthy <j-keerthy@xxxxxx> wrote: >> On Thursday 27 October 2016 01:23 PM, Roger Quadros wrote: >>> On 27/10/16 06:42, Keerthy wrote: >>>> On Sunday 23 October 2016 04:02 PM, Linus Walleij wrote: >>>>> On Wed, Oct 19, 2016 at 7:33 AM, Keerthy <j-keerthy@xxxxxx> wrote: >>>>>> From: Lokesh Vutla <lokeshvutla@xxxxxx> > >>>> In case of k2g. There are 2 big GPIO modules GPIO0 and GPIO1. >>>> GPIO0 comprises of 144 GPIOs >>>> and GPIO1 has about 68 GPIOs. Wanted feedback from you on how this is >>>> being modeled. >>>> >>>> I am creating a controller for every 32 GPIOs under the big module each >>>> containing a gpio_chip. Each 32 GPIOs chip has 2 banks of 16 GPIOs each. >>>> Each 16 GPIO bank has an interrupt. >>>> >>>> Is this modeling fine or do you think creating one chip with 144 pins and >>>> another with 68 pins is a better way? >>> >>> >>> If GPIO0 has 144 GPIOs, why don't we model it as a gpiochip with 144 >>> GPIOs? >>> What is the benefit of partitioning it into gpiochips of 32 GPIOs each? >> >> 144 GPIOs where in 16 GPIOs form a bank. So about 9 banks with one interrupt >> each. So split it into gpiochips with 32 GPIOs each handling 2 Interrupts. > > I'm a bit confused. > > This sounds like you should either have one gpio_chip per interrupt > (if that fits with how the device tree looks) or one big gpio_chip for > all the lines. yep. This HW confuses a bit :(, So, there are few links on TRMs/DM and my brief overview: Keystone k2g (66AK2G02) http://www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf Keystone k2hk/e/l http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf omap-l138 http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf Each GPIO IP is implemented as GPIO controller which has some set of common registers (minimum BINTEN) and up to 16 (?) gpio banks - 16 pins per bank. SoC may contain more than one GPIO controllers. GPIO banks groped by two in 32 bit registers, so overall registers structure: common 0h GPIO_PID Peripheral Identification Register common 8h GPIO_BINTEN Interrupt Per-Bank Enable Register banks0&1 10h GPIO_DIR01 Direction 0 and 1 Register 14h GPIO_OUT_DATA01 Output Data 0 and 1 Register 18h GPIO_SET_DATA01 Set Data 0 and 1 Register 1Ch GPIO_CLR_DATA01 Clear Data 0 and 1 Register 20h GPIO_IN_DATA01 Input Data 0 and 1 24h GPIO_SET_RIS_TRIG01 Set Rising Edge Interrupt 0 and 1 28h GPIO_CLR_RIS_TRIG01 Clear Rising Edge Interrupt 0 and 1 2Ch GPIO_SET_FAL_TRIG01 Set Falling Edge Interrupt 0 and 1 30h GPIO_CLR_FAL_TRIG01 Clear Falling Edge Interrupt 0 and 1 34h GPIO_INTSTAT01 GPIO Interrupt status 0 and 1 Register banks2&3 38h DIR23 GPIO Banks 2 and 3 Direction Register ... IRQ handling can be done in two ways - depending on SoC - which can be combined on some SoCs (not supported by current driver) 1) Direct IRQs - each GPIO pin has separate IRQ line assigned in Main IRQ controller (example k2hk/e/l) 2) banked IRQs - each bank (16 pins) has one assigned IRQ. So, two IRQs per banksX&Y register set. > > The DT model sort of mandates how the interrupts should be mapped > at this point, and as far as I can tell from the binding the example looks > like so: > > gpio: gpio@1e26000 { > compatible = "ti,dm6441-gpio"; > gpio-controller; > #gpio-cells = <2>; > reg = <0x226000 0x1000>; > interrupt-parent = <&intc>; > interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH > 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH > 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH > 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH > 50 IRQ_TYPE_EDGE_BOTH>; > ti,ngpio = <144>; > ti,davinci-gpio-unbanked = <0>; > interrupt-controller; > #interrupt-cells = <2>; > }; Above, DT bindings models Davinci GPIO IP as monolithic GPIO controller with N gpio pins, but internally separate GPIO chips are created for each banksX&Y register set (32 pins, 2 banked irq -or- 32 direct irqs). Translation from linear GPIO numbering to the proper internal GPIO chip is done using chip.of_xlate(). > > So I don't see any reason to split this up in subchips internally in > Linux? > -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
