devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keerthy <j-keerthy@ti.com>
To: Roger Quadros <rogerq@ti.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Alexandre Courbot <gnurou@gmail.com>,
	Lokesh Vutla <lokeshvutla@ti.com>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux-OMAP <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 2/5] drivers: gpio: Add support for multiple IPs
Date: Thu, 27 Oct 2016 13:37:21 +0530	[thread overview]
Message-ID: <c047fb27-a8bb-c10d-2b16-a3e6bf45d88f@ti.com> (raw)
In-Reply-To: <98447580-cbc4-152e-f2cb-7c4756545479@ti.com>



On Thursday 27 October 2016 01:23 PM, Roger Quadros wrote:
> Keerthy,
>
> 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@ti.com> wrote:
>>>
>>>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>>>
>>>> Update GPIO driver to support Multiple GPIO IPs.
>>>>
>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>>
>>> This commit message is not at all describing what the patch is doing.
>>>
>>> What it does is bumping the GPIO pin offset in the Linux global
>>> GPIO number space with 32 for each new controller.
>>>
>>>> +       static int bank_base;
>>>>
>>>>         pdata = davinci_gpio_get_pdata(pdev);
>>>>         if (!pdata) {
>>>> @@ -226,7 +227,8 @@ static int davinci_gpio_probe(struct platform_device *pdev)
>>>>                 chips[i].chip.direction_output = davinci_direction_out;
>>>>                 chips[i].chip.set = davinci_gpio_set;
>>>>
>>>> -               chips[i].chip.base = base;
>>>> +               chips[i].chip.base = bank_base;
>>>> +               bank_base += 32;
>>>
>>> Why can you not rewrite the driver to pass -1 as base and
>>> get a dynamic allocation of GPIO numbers instead? Then
>>> you won't have this hairy problem.
>>
>> Ok i will try that.
>>
>> 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.

Grygorii,

Any strong reason that you recollect of so as to why this modeling was 
chosen?

>
> cheers,
> -roger
>

  reply	other threads:[~2016-10-27  8:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-19  5:33 [PATCH 0/5] gpio: davinci: Add k2g support Keerthy
2016-10-19  5:33 ` [PATCH 1/5] gpio: davinci: Remove gpio2regs function to accommodate multi instances Keerthy
2016-10-19  5:33 ` [PATCH 4/5] gpio: davinci: Store both irqs into the controller Keerthy
     [not found] ` <1476855239-32730-1-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
2016-10-19  5:33   ` [PATCH 2/5] drivers: gpio: Add support for multiple IPs Keerthy
     [not found]     ` <1476855239-32730-3-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
2016-10-23 10:32       ` Linus Walleij
     [not found]         ` <CACRpkdbsgM-yiWpiA5G35jQR8v3FO=Me+4rhe6TzE0qsWOJ8Ew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-27  3:42           ` Keerthy
2016-10-27  7:53             ` Roger Quadros
2016-10-27  8:07               ` Keerthy [this message]
     [not found]                 ` <c047fb27-a8bb-c10d-2b16-a3e6bf45d88f-l0cyMroinI0@public.gmane.org>
2016-10-31 14:58                   ` Grygorii Strashko
2016-11-04 14:28                   ` Linus Walleij
     [not found]                     ` <CACRpkdZmuc__QL6b7Jvb8xL5Bm+PD2X60NtiugrnH7iAO=-tLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-04 19:59                       ` Grygorii Strashko
     [not found]                         ` <b92f729b-5897-c29a-31ec-97510776d85d-l0cyMroinI0@public.gmane.org>
2016-11-05  8:23                           ` Linus Walleij
     [not found]                             ` <CACRpkdac_UgM=xeXkSZ+rOvZvutt40USjCoEt5-SoFkqspuExw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-07  3:59                               ` Keerthy
2016-10-19  5:33   ` [PATCH 3/5] gpio: davinci: irq support for multiple gpio controllers Keerthy
2016-10-19  5:33   ` [PATCH 5/5] gpio: davinci: Add a separate compatible for k2g Keerthy
     [not found]     ` <1476855239-32730-6-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
2016-10-26 21:08       ` Rob Herring
2016-10-27  3:28         ` Keerthy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c047fb27-a8bb-c10d-2b16-a3e6bf45d88f@ti.com \
    --to=j-keerthy@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gnurou@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=rogerq@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).