Re: [PATCH 7/7] mfd: Add support for the MediaTek MT6397 PMIC

[Sascha Hauer]

On Fri, Jan 23, 2015 at 04:14:40PM +0000, Lee Jones wrote:
> On Fri, 23 Jan 2015, Sascha Hauer wrote:
> 
> > From: Flora Fu <flora.fu@xxxxxxxxxxxx>
> > 
> > This adds support for the MediaTek MT6397 PMIC. This is a
> > multifunction device with the following sub modules:
> > 
> > - Regulator
> > - RTC
> > - Audio codec
> > - GPIO
> > - Clock
> > 
> > It is interfaced to the host controller using SPI interface by a proprietary
> > hardware called PMIC wrapper or pwrap. MT6397 MFD is a child device of the
> > pwrap.
> > 
> > Signed-off-by: Flora Fu, MediaTek
> > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> > Cc: Samuel Ortiz <sameo@xxxxxxxxxxxxxxx>
> > Cc: Lee Jones <lee.jones@xxxxxxxxxx>
> > ---
> >  Documentation/devicetree/bindings/mfd/mt6397.txt |  70 +++++
> 
> This should be submitted seperately, as per:
> 
>   Documentation/devicetree/bindings/submitting-patches.txt

I didn't know this document yet, thanks for noting. I thought it is still
acceptable to combine patches adding both code and the binding docs.

> 
> >  drivers/mfd/Kconfig                              |  10 +
> >  drivers/mfd/Makefile                             |   1 +
> >  drivers/mfd/mt6397-core.c                        | 251 ++++++++++++++++
> >  include/linux/mfd/mt6397/core.h                  |  76 +++++
> >  include/linux/mfd/mt6397/registers.h             | 362 +++++++++++++++++++++++
> >  6 files changed, 770 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/mt6397.txt
> >  create mode 100644 drivers/mfd/mt6397-core.c
> >  create mode 100644 include/linux/mfd/mt6397/core.h
> >  create mode 100644 include/linux/mfd/mt6397/registers.h
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > new file mode 100644
> > index 0000000..25b40a6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > @@ -0,0 +1,70 @@
> > +MediaTek MT6397 Multifunction Device Driver
> > +
> > +MT6397 is a multifunction device with the following sub modules:
> > +- Regulator
> > +- RTC
> > +- Audio codec
> > +- GPIO
> > +- Clock
> > +
> > +It is interfaced to host controller using SPI interface by a proprietary hardware
> > +called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.
> > +See the following for pwarp node definitions:
> > +Documentation/devicetree/bindings/soc/pwrap.txt
> > +
> > +This document describes the binding for mfd device and its sub module.
> 
> Nit: s/mfd/MFD/
> 
> > +Required properties:
> > +compatible: "mediatek,mt6397"
> > +
> > +Optional subnodes:
> > +
> > +- rtc:
> > +	Required properties:
> > +		- compatible: "mediatek,mt6397-rtc",
> > +- regulators
> > +	Required properties:
> > +		- compatible: "mediatek,mt6397-regulator",
> > +	see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> > +- codec
> > +	Required properties:
> > +		- compatible: "mediatek,mt6397-codec",
> > +- clk
> > +	Required properties:
> > +		- compatible: "mediatek,mt6397-clk",
> 
> Nit: Titles with or without ':', as long as it's consistent.
> 
> Drop the comma at the end of each compatible line.
> 
> > +Example:
> > +	pwrap: pwrap@1000f000 {
> > +		compatible = "mediatek,mt8135-pwrap";
> > +
> > +		...
> > +
> > +		pmic {
> > +			compatible = "mediatek,mt6397";
> > +
> > +			codec: mt6397codec {
> > +				compatible = "mediatek,mt6397-codec";
> > +			};
> > +
> > +			mt6397regulator: mt6397regulator {
> 
> s/mt6397regulator/regulator/

Dropped the label completely since consumers will point to the
individual regulators, not this node.

> > diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> > new file mode 100644
> > index 0000000..9710fca
> > --- /dev/null
> > +++ b/drivers/mfd/mt6397-core.c
> > @@ -0,0 +1,251 @@
> > +/*
> > + * Copyright (c) 2014 MediaTek Inc.
> > + * Author: Flora Fu, MediaTek
> 
> Email address?

She does not work for MediaTek anymore. Her Email address is no longer
valid, so I removed it but kept her credits in the driver.

> > +{
> > +	return irq >> 4;
> > +}
> > +
> > +static void mt6397_irq_lock(struct irq_data *data)
> > +{
> > +	struct mt6397_chip *mt6397 = irq_get_chip_data(data->irq);
> > +
> > +	mutex_lock(&mt6397->irqlock);
> > +}
> > +
> > +static void mt6397_irq_sync_unlock(struct irq_data *data)
> > +{
> > +	int i;
> > +	struct mt6397_chip *mt6397 = irq_get_chip_data(data->irq);
> > +
> > +	regmap_write(mt6397->regmap, MT6397_INT_CON0, mt6397->irq_masks_cur[0]);
> > +	regmap_write(mt6397->regmap, MT6397_INT_CON1, mt6397->irq_masks_cur[1]);
> > +
> > +	mutex_unlock(&mt6397->irqlock);
> > +}
> > +
> > +static void mt6397_irq_mask(struct irq_data *data)
> > +{
> > +	struct mt6397_chip *mt6397 = irq_get_chip_data(data->irq);
> > +	int shift = mt6397_irq_shift(data->hwirq);
> > +	int reg = mt6397_irq_reg(data->hwirq);
> > +	int reg_ofs = MT6397_INT_CON0 + reg * 2;
> > +
> > +	mt6397->irq_masks_cur[reg] &= ~(1 << shift);
> 
> s/(1 << shift)/BIT(shift)/

Is it mentioned somewhere that these BIT macros shall be used? There are
quadrillions of examples for both styles in the kernel and personally I
think 1 << x is more readable.

> > +	for (i = 0; i < MT6397_IRQ_GROUP_NR; i++) {
> > +		ret = regmap_read(mt6397->regmap,
> > +			MT6397_INT_STATUS0 + i * 2, &irq_reg[i]);
> > +		if (ret > 0) {
> 
> Can regmap_read() return <0?

Yes, but not > 0 ;). Fixed.

> 
> > +			dev_err(mt6397->dev,
> > +				"failed to read interrupt status [0x%x]\n",
> > +				MT6397_INT_STATUS0 + i * 2);
> > +			return IRQ_NONE;
> > +		}
> > +	}
> > +
> > +	for (i = 0; i < MT6397_IRQ_NR; i++) {
> > +		int shift = mt6397_irq_shift(i);
> > +		int reg = mt6397_irq_reg(i);
> > +		int reg_ofs = MT6397_INT_STATUS0 + reg * 2;
> > +
> > +		if (irq_reg[reg] & (1 << shift)) {
> > +			cur_irq = irq_find_mapping(mt6397->irq_domain, i);
> > +			if (cur_irq)
> > +				handle_nested_irq(cur_irq);
> > +
> > +			/* write 1 to status bit to clear the event.  */
> 
> There are very few comments in the driver and _this_ is where it was
> felt appropriate to do so?  If you put "MT6397_INT_STATUS0 + reg * 2"
> directly into the call, the line will speak for itself.

I refactored the code a bit, like write status reg once after handling
all interrupts and not after each interrupt. I also removed this comment
since it only states the obvious.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/