From: Bin Gao <bin.gao@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
Alexandre Courbot <gnurou@gmail.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>,
Bin Gao <bin.gao@intel.com>
Subject: Re: [PATCH] gpio: add Intel WhiskeyCove GPIO driver
Date: Mon, 13 Jun 2016 15:40:50 -0700 [thread overview]
Message-ID: <20160613224050.GA213010@worksta> (raw)
In-Reply-To: <CACRpkdY632ooGJWVBVAUXdTvFNkFnnadey4LUGh9u+GvMrt=jA@mail.gmail.com>
On Mon, Jun 13, 2016 at 02:43:16PM +0200, Linus Walleij wrote:
> On Sat, Jun 11, 2016 at 8:01 AM, Bin Gao <bin.gao@linux.intel.com> wrote:
>
> > This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC.
> > This driver is based on gpio-crystalcove.c.
> >
> > Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
> > Signed-off-by: Bin Gao <bin.gao@intel.com>
>
> It is always good to let Mika and Mathias look at new Intel GPIO
> drivers, so added them to the To: line.
>
> > +config GPIO_WHISKEY_COVE
> > + tristate "GPIO support for Whiskey Cove PMIC"
> > + depends on INTEL_SOC_PMIC
> > + select GPIOLIB_IRQCHIP
> > + help
> > + Support for GPIO pins on Whiskey Cove PMIC.
> > +
> > + Say Yes if you have a Intel SoC based tablet with Whsikey Cove PMIC
>
> Speling
>
> > +#include <linux/interrupt.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/gpio.h>
>
> No use just #include <linux/gpio/driver.h>
>
> > +#include <linux/seq_file.h>
> > +#include <linux/bitops.h>
> > +#include <linux/regmap.h>
> > +#include <linux/mfd/intel_soc_pmic.h>
> > +
> > +#define WCOVE_GPIO_NUM 13
> > +#define WCOVE_VGPIO_NUM 94
> > +
> > +#define UPDATE_IRQ_TYPE BIT(0)
> > +#define UPDATE_IRQ_MASK BIT(1)
> > +
> > +#define GPIOIRQ0 0x4e0b
> > +#define GPIOIRQ1 0x4e0c
> > +#define MGPIOIRQ0 0x4e19
> > +#define MGPIOIRQ1 0x4e1a
> > +#define GPIO0P0CTLO 0x4e44
> > +#define GPIO0P0CTLI 0x4e51
> > +#define GPIO1P0CTLO 0x4e4b
> > +#define GPIO1P0CTLI 0x4e58
> > +#define GPIO2P0CTLO 0x4e4f
> > +#define GPIO2P0CTLI 0x4e5c
> > +
> > +#define CTLI_INTCNT_DIS (0)
> > +#define CTLI_INTCNT_NE (1 << 1)
> > +#define CTLI_INTCNT_PE (2 << 1)
> > +#define CTLI_INTCNT_BE (3 << 1)
> > +
> > +#define CTLO_DIR_IN (0)
> > +#define CTLO_DIR_OUT (1 << 5)
> > +
> > +#define CTLO_DRV_CMOS (0)
> > +#define CTLO_DRV_OD (1 << 4)
>
> That is likely what we call push-pull and open drain driving.
> Implement .set_single_ended() for this driver so you can handle
> that properly in the driver.
>
> > +#define CTLO_DRV_REN (1 << 3)
> > +
> > +#define CTLO_RVAL_2KDW (0)
> > +#define CTLO_RVAL_2KUP (1 << 1)
> > +#define CTLO_RVAL_50KDW (2 << 1)
> > +#define CTLO_RVAL_50KUP (3 << 1)
>
> Looks like pull-up settings. That is strictly speaking pin control.
>
> But OK I am trying to find the right way to abstract this without
> making GPIO too heavyweight.
>
> > +static inline struct wcove_gpio *to_wg(struct gpio_chip *gc)
> > +{
> > + return container_of(gc, struct wcove_gpio, chip);
> > +}
>
> No don't do that. Use devm_gpiochip_add_data() and just
> use gpiochip_get_data() to get the pointer out. Look at any
> other driver in the upstream kernel, I think I converted them all.
>
> > +static inline int to_reg(int gpio, enum ctrl_register reg_type)
> > +{
> > + int reg;
> > +
> > + if (reg_type == CTRL_IN) {
> > + if (gpio < 7)
> > + reg = GPIO0P0CTLI + gpio;
> > + else if (gpio < 11)
> > + reg = GPIO1P0CTLI + (gpio % 7);
> > + else
> > + reg = GPIO2P0CTLI + (gpio % 11);
> > + } else {
> > + if (gpio < 7)
> > + reg = GPIO0P0CTLO + gpio;
> > + else if (gpio < 11)
> > + reg = GPIO1P0CTLO + (gpio % 7);
> > + else
> > + reg = GPIO2P0CTLO + (gpio % 11);
> > + }
> > +
> > + return reg;
> > +}
>
> You could add a kerneldoc to this function explaining how these
> GPIO registers are laid out.
>
> > +static void wcove_gpio_set(struct gpio_chip *chip,
> > + unsigned int gpio, int value)
> > +{
> > + struct wcove_gpio *wg = to_wg(chip);
> > +
> > + if (gpio > WCOVE_VGPIO_NUM)
> > + return;
>
> gpiolib already protects against this, you can drop it everywhere.
>
> > +static irqreturn_t wcove_gpio_irq_handler(int irq, void *data)
> > +{
> > + struct wcove_gpio *wg = data;
> > + unsigned int p0, p1, virq;
> > + int pending, gpio;
> > +
> > + if (regmap_read(wg->regmap, GPIOIRQ0, &p0) ||
> > + regmap_read(wg->regmap, GPIOIRQ1, &p1))
> > + return IRQ_NONE;
>
> What does this mean? If we fail to read regmaps then
> it was not our IRQ?
>
> Should be an error message or something at least I think?
>
> Apart from that it looks all right.
>
> Yours,
> Linus Walleij
Linus,
Thank you for your review. We'll come up with a version 2.
-Bin
next prev parent reply other threads:[~2016-06-13 22:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 6:01 [PATCH] gpio: add Intel WhiskeyCove GPIO driver Bin Gao
2016-06-13 12:43 ` Linus Walleij
2016-06-13 22:40 ` Bin Gao [this message]
2016-06-14 10:09 ` Mika Westerberg
2016-06-14 23:39 ` Bin Gao
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=20160613224050.GA213010@worksta \
--to=bin.gao@linux.intel.com \
--cc=ajay.thomas.david.rajamanickam@intel.com \
--cc=bin.gao@intel.com \
--cc=gnurou@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=mika.westerberg@linux.intel.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).