From: Grant Likely <grant.likely@linaro.org>
To: Rohit Vaswani <rvaswani@codeaurora.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
Rob Landley <rob@landley.net>,
Russell King <linux@arm.linux.org.uk>,
David Brown <davidb@codeaurora.org>,
Bryan Huntsman <bryanh@codeaurora.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCHv4 3/3] gpio: msm: Add device tree and irqdomain support for gpio-msm-v2
Date: Wed, 05 Jun 2013 22:38:13 +0100 [thread overview]
Message-ID: <20130605213813.2D9703E10E4@localhost> (raw)
In-Reply-To: <51AC0005.2020700@codeaurora.org>
On Sun, 02 Jun 2013 19:31:33 -0700, Rohit Vaswani <rvaswani@codeaurora.org> wrote:
> On 6/1/2013 1:09 AM, Grant Likely wrote:
> > On Sat, Jun 1, 2013 at 1:22 AM, Rohit Vaswani <rvaswani@codeaurora.org> wrote:
> >> This cleans up the gpio-msm-v2 driver of all the global define usage.
> >> The number of gpios are now defined in the device tree. This enables
> >> adding irqdomain support as well.
> >>
> >> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> >> @@ -101,11 +96,27 @@ enum {
> >> */
> >> struct msm_gpio_dev {
> >> struct gpio_chip gpio_chip;
> >> - DECLARE_BITMAP(enabled_irqs, NR_GPIO_IRQS);
> >> - DECLARE_BITMAP(wake_irqs, NR_GPIO_IRQS);
> >> - DECLARE_BITMAP(dual_edge_irqs, NR_GPIO_IRQS);
> >> + unsigned long *enabled_irqs;
> >> + unsigned long *wake_irqs;
> >> + unsigned long *dual_edge_irqs;
> > Was there a reason you ignored the comment to leave these bitmaps as
> > statically allocated?
> >
> > [...]
> >
> >> + msm_gpio.enabled_irqs = devm_kzalloc(&pdev->dev,
> >> + sizeof(unsigned long) *
> >> + BITS_TO_LONGS(ngpio) * 3,
> >> + GFP_KERNEL);
> >> + msm_gpio.wake_irqs = &msm_gpio.enabled_irqs[BITS_TO_LONGS(ngpio)];
> >> + msm_gpio.dual_edge_irqs =
> >> + &msm_gpio.enabled_irqs[BITS_TO_LONGS(ngpio * 2)];
> > I should have just deleted my comment about doing it this way. I was
> > making the point that one allocation is better that three; but then I
> > also said that it was better to not allocate at all. Go back to the
> > statically allocated bitmap array. It is far better than this.
> >
> > g.
>
> I agree that DECLARE_BITMAP is the most efficient way, but
> DECLARE_BITMAP takes a statically defined number of gpios as an
> argument. Since we get the ngpio from device tree, these had to go as
> well. Under this scheme, 1 allocation was better than 3 and went ahead
> with your suggestion.
Think about it for a moment; You *know* all the devices that are going
to use the driver. The largest size for ngpios that I see is 173 which
is a mere 18 long words for 3 bitmaps. Even if you were to quadruple
that amount the total for all the bitmasks is 72 long words. You're
optimizing at the wrong place. Changing it to dynamic allocation makes
the code slower, more complicated, and probably doesn't do anything to
save on real memory consumption.
The solution is simple; choose a maximum value of ngpios that the driver
will likely need to work support. If a device appears with more GPIOs,
then the driver should throw a warning and work with the maximum it can
support. Part of enablement for the new device will be increasing the
driver to handle more gpios.
g.
next prev parent reply other threads:[~2013-06-05 21:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 0:21 [PATCHv4 0/3] Cleanup MSM_GPIOMUX and add DT support for gpio-msm Rohit Vaswani
2013-06-01 0:21 ` [PATCH 1/3] ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs Rohit Vaswani
2013-06-17 5:36 ` Linus Walleij
2013-06-01 0:22 ` [PATCH 2/3] ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60 Rohit Vaswani
2013-06-01 0:22 ` [PATCHv4 3/3] gpio: msm: Add device tree and irqdomain support for gpio-msm-v2 Rohit Vaswani
2013-06-01 8:09 ` Grant Likely
2013-06-03 2:31 ` Rohit Vaswani
2013-06-05 21:38 ` Grant Likely [this message]
2013-06-10 22:46 ` Rohit Vaswani
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=20130605213813.2D9703E10E4@localhost \
--to=grant.likely@linaro.org \
--cc=bryanh@codeaurora.org \
--cc=davidb@codeaurora.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=rvaswani@codeaurora.org \
/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).