From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Cc: linus.walleij@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
robh@kernel.org, qi-ming.wu@intel.com, yixin.zhu@linux.intel.com,
cheol.yong.kim@intel.com
Subject: Re: [PATCH v2 1/2] pinctrl: Add pinmux & GPIO controller driver for a new SoC
Date: Wed, 30 Oct 2019 16:39:07 +0200 [thread overview]
Message-ID: <20191030143907.GY32742@smile.fi.intel.com> (raw)
In-Reply-To: <4bb885fe692d29f2635772dcd04839390f1f5671.1572409172.git.rahul.tanwar@linux.intel.com>
On Wed, Oct 30, 2019 at 12:23:59PM +0800, Rahul Tanwar wrote:
> Intel Lightning Mountain SoC has a pinmux controller & GPIO controller IP which
> controls pin multiplexing & configuration including GPIO functions selection &
> GPIO attributes configuration.
>
> This IP is not based on & does not have anything in common with Chassis
> specification. The pinctrl drivers under pinctrl/intel/* are all based upon
> Chassis spec compliant pinctrl IPs. So this driver doesn't fit & can not use
> pinctrl framework under pinctrl/intel/* and it requires a separate new driver.
>
> Add a new GPIO & pin control framework based driver for this IP.
Thanks for an update, my comments below.
> +#define PIN_NAME_FMT "io-%d"
> +#define PIN_NAME_LEN 10
> +static inline void eqbr_set_val(void __iomem *addr, u32 offset,
> + u32 mask, u32 set, raw_spinlock_t *lock)
Why is it marked with inline?
> +{
> + u32 val;
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(lock, flags);
> + val = readl(addr);
> + val = (val & ~(mask << offset)) | ((set & mask) << offset);
This is unusual, why offset can't be applied once to the mask?
> + writel(val, addr);
> + raw_spin_unlock_irqrestore(lock, flags);
Hmm... Don't you have more complicated workflow that requires few
reads/writes/updates to be called atomically?
> +}
> +static void eqbr_gpio_disable_irq(struct irq_data *d)
> +{
> + unsigned int offset = irqd_to_hwirq(d);
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> + struct eqbr_gpio_desc *desc = gpiochip_get_data(gc);
> + writel(BIT(offset), desc->membase + GPIO_IRNENCLR);
Is it okay to be without spin lock?
Same Q to the rest similar places.
> +}
> +static inline void eqbr_cfg_bit(void __iomem *addr,
> + unsigned int offset, unsigned int set)
> +{
> + if (!set)
Why not to use positive condition?
> + writel(readl(addr) & ~BIT(offset), addr);
> + else
> + writel(readl(addr) | BIT(offset), addr);
> +}
> + struct gpio_irq_type it;
Not sure if this is used properly. Linus may clarify this.
> +static void eqbr_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct eqbr_gpio_desc *gpio_desc = gpiochip_get_data(gc);
> + struct irq_chip *ic = irq_desc_get_chip(desc);
> + u32 pins, offset;
> +
> + chained_irq_enter(ic, desc);
> + pins = readl(gpio_desc->membase + GPIO_IRNCR);
> +
> + for_each_set_bit(offset, (unsigned long *)&pins, gc->ngpio)
This casting is no go.
> + generic_handle_irq(irq_find_mapping(gc->irq.domain, offset));
> +
> + chained_irq_exit(ic, desc);
> +}
> +static int gpiochip_setup(struct device *dev, struct eqbr_gpio_desc *desc)
> +{
> + struct gpio_irq_chip *girq;
> + struct gpio_chip *gc;
> +
> + gc = &desc->chip;
> + gc->owner = THIS_MODULE;
Do we still need this in the drivers?
> + gc->label = desc->name;
> + gc->of_node = desc->node;
> +
> + if (!of_property_read_bool(desc->node, "interrupt-controller")) {
Why is it fatal?
> + dev_info(dev, "gc %s: doesn't act as interrupt controller!\n",
> + desc->name);
> + return 0;
> + }
> + girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
> + GFP_KERNEL);
I believe it's fine to have it on one line.
> + if (!girq->parents)
> + return -ENOMEM;
> +
> + girq->default_type = IRQ_TYPE_NONE;
> + girq->handler = handle_level_irq;
Not bad IRQ handler?
> + girq->parents[0] = desc->virq;
> +
> + return 0;
> +}
> +static int gpiolib_reg(struct eqbr_pinctrl_drv_data *drvdata)
> +{
> + struct device_node *np;
> + struct eqbr_gpio_desc *desc;
> + struct device *dev;
> + int i, ret;
> + struct resource res;
> +
> + dev = drvdata->dev;
> + for (i = 0; i < drvdata->nr_gpio_descs; i++) {
> + desc = drvdata->gpio_desc + i;
> + np = desc->node;
> +
> + desc->name = devm_kasprintf(dev, GFP_KERNEL, "gpiochip%d", i);
> + if (!desc->name)
> + return -ENOMEM;
> +
> + if (of_address_to_resource(np, 0, &res)) {
> + dev_err(dev, "Failed to get GPIO register address\n");
> + return -ENXIO;
> + }
> +
> + desc->membase = devm_ioremap_resource(dev, &res);
> + if (IS_ERR(desc->membase)) {
> + dev_err(dev, "ioremap fail\n");
Redundant.
> + return PTR_ERR(desc->membase);
> + }
Is it per descriptor?!
> +
> + desc->virq = irq_of_parse_and_map(np, 0);
> + if (!desc->virq) {
> + dev_err(dev, "%s: failed to parse and map irq\n",
> + desc->name);
> + return -ENXIO;
> + }
> + raw_spin_lock_init(&desc->lock);
> + }
> +
> + return 0;
> +}
> +static const struct pinmux_ops eqbr_pinmux_ops = {
> + .get_functions_count = pinmux_generic_get_function_count,
> + .get_function_name = pinmux_generic_get_function_name,
> + .get_function_groups = pinmux_generic_get_function_groups,
> + .set_mux = eqbr_pinmux_set_mux,
> + .gpio_request_enable = eqbr_pinmux_gpio_request,
> + .strict = true,
> +};
TABs/spaces mix.
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2019-10-30 14:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 4:23 [PATCH v2 0/2] pinctrl: Add new pinctrl/GPIO driver Rahul Tanwar
2019-10-30 4:23 ` [PATCH v2 1/2] pinctrl: Add pinmux & GPIO controller driver for a new SoC Rahul Tanwar
2019-10-30 14:39 ` Andy Shevchenko [this message]
2019-10-31 7:57 ` Tanwar, Rahul
2019-11-01 8:14 ` kbuild test robot
2019-11-01 8:14 ` kbuild test robot
2019-10-30 4:24 ` [PATCH v2 2/2] dt-bindings: pinctrl: intel: Add for " Rahul Tanwar
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=20191030143907.GY32742@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=cheol.yong.kim@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=qi-ming.wu@intel.com \
--cc=rahul.tanwar@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=yixin.zhu@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.