Re: [PATCH] [trivial] mfd: tmio: Typo s/use use/use/
On Wed, 07 Nov 2018, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > include/linux/mfd/tmio.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V2] mfd: dt: Add bindings for DA9063L
On Wed, 23 May 2018, Marek Vasut wrote: > Add device tree bindings for the Dialog DA9063L. This is a > variant of the DA9063 chip with smaller package, with less > LDO regulators and without RTC block. The other properties > of the chip are the same, including the content of the chip > ID register. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Lee Jones > Cc: Rob Herring > Cc: Steve Twiss > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org > --- > V2: Merge the DA9063/DA9063L regulator lists and mark DA9063-only > regulators in that single list > --- > Documentation/devicetree/bindings/mfd/da9063.txt | 32 > +--- > 1 file changed, 17 insertions(+), 15 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction
On Tue, 24 Apr 2018, Geert Uytterhoeven wrote:
> On Tue, Apr 24, 2018 at 10:41 AM, Simon Horman <ho...@verge.net.au> wrote:
> > On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote:
> >> On Wed, 11 Apr 2018, Simon Horman wrote:
> >> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> >> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> >> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> >> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> >> > > fix this user (until a better, system-wide solution is in place).
> >> > >
> >> > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> >> > > Acked-by: Daniel Thompson <daniel.thomp...@linaro.org>
> >> >
> >> > Reviewed-by: Simon Horman <horms+rene...@verge.net.au>
> >>
> >> Thanks for the Reviewed-by Simon. I have applied it to the original mail.
> >>
> >> Do you know why you mail wasn't sent attached to the original thread?
> >> For some reason I received this mail on it's own i.e. not in reply
> >> to the original.
> >
> > No, not off hand. Perhaps I responded to the email in some unusual way
> > but by now I don't recall. In any case I'll try to be more careful
> > in future.
>
> I see Lee is using gmail for sending, so I assume also for receiving.
Well I'm using their servers, but my set-up is IMAP/Mutt.
> While I did receive Simon's reply in-thread, lately I had issues with gmail
> not always doing so, and sometimes failing to do deduplication when receiving
> email through multiple paths (mailing lists and/or directly).
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 0/4] regulator: bd9571mwv: Add support for DDR backup mode
On Fri, 20 Apr 2018, Geert Uytterhoeven wrote: > On Fri, Apr 20, 2018 at 9:49 AM, Lee Jones <lee.jo...@linaro.org> wrote: > > On Wed, 18 Apr 2018, Geert Uytterhoeven wrote: > >> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB > >> development boards supports DDR Backup Power, which means that the DDR > >> power rails can be kept powered while the main SoC is powered down. > > > > Should this set be applied together, or can the MFD patches be applied > > on their own, without the Regulator patch? > > The regulator patch depends on the MFD patches, so it's best for them to > go in together. > > > If the former, then we're going to need an Ack from Mark. > > Alternative, as you've already supplied (some form of) your Ack for the firs > 3 patches, they can go in through Mark? All of it is enhancing the > regulator part. Yes, that's fine too: Acked-by: Lee Jones <lee.jo...@linaro.org> -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 0/4] regulator: bd9571mwv: Add support for DDR backup mode
On Wed, 18 Apr 2018, Geert Uytterhoeven wrote: > Hi all, > > The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB > development boards supports DDR Backup Power, which means that the DDR > power rails can be kept powered while the main SoC is powered down. Should this set be applied together, or can the MFD patches be applied on their own, without the Regulator patch? If the former, then we're going to need an Ack from Mark. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4] gpio: dwapb: Add support for 1 interrupt per port A GPIO
On Tue, 17 Apr 2018, Phil Edworthy wrote: > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the driver currently only supports 1 interrupt. > See the DesignWare DW_apb_gpio Databook description of the > 'GPIO_INTR_IO' parameter. > > This change allows the driver to work with up to 32 interrupts, it will > get as many interrupts as specified in the DT 'interrupts' property. > It doesn't do anything clever with the different interrupts, it just calls > the same handler used for single interrupt hardware. > > Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com> > --- > One point to mention is that I have made it possible for users to have > unconncted interrupts by specifying holes in the list of interrupts. This is > done by supporting the interrupts-extended DT prop. > However, I have no use for this and had to hack some test case for this. > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts? > > v4: > - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping() > v3: > - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect > problems > v2: > - Replaced interrupt-mask DT prop with support for the interrupts-extended >prop. This means replacing the call to irq_of_parse_and_map() with calls >to of_irq_parse_one() and irq_create_of_mapping(). > > Note: There are a few *code* lines over 80 chars, but this is just guidance, >right? Especially as there are already some lines over 80 chars. > > snps:gpio fix > > Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com> > --- > .../devicetree/bindings/gpio/snps-dwapb-gpio.txt | 9 +++-- > drivers/gpio/gpio-dwapb.c | 42 > +- > drivers/mfd/intel_quark_i2c_gpio.c | 3 +- If Linus, is happy with the GPIO implementation, then the changes in MFD look fine: Acked-by: Lee Jones <lee.jo...@linaro.org> -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction
On Wed, 11 Apr 2018, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> > fix this user (until a better, system-wide solution is in place).
> >
> > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> > Acked-by: Daniel Thompson <daniel.thomp...@linaro.org>
>
> Reviewed-by: Simon Horman <horms+rene...@verge.net.au>
Thanks for the Reviewed-by Simon. I have applied it to the original mail.
Do you know why you mail wasn't sent attached to the original thread?
For some reason I received this mail on it's own i.e. not in reply
to the original.
> > ---
> >
> > Changes since V1:
> > * rebased to top-of-linus-tree
> > * added tag from Daniel, thanks!
> >
> > Through which tree does this need to go?
> >
> > drivers/video/backlight/pwm_bl.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c
> > index 1c2289ddd555..0fa7d2bd0e48 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device
> > *pdev)
> >
> > /*
> > * If the GPIO is not known to be already configured as output, that
> > -* is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
> > -* change the direction to output and set the GPIO as active.
> > +* is, if gpiod_get_direction returns either 1 or -EINVAL, change the
> > +* direction to output and set the GPIO as active.
> > * Do not force the GPIO to active when it was already output as it
> > * could cause backlight flickering or we would enable the backlight too
> > * early. Leave the decision of the initial backlight state for later.
> > */
> > if (pb->enable_gpio &&
> > - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> > + gpiod_get_direction(pb->enable_gpio) != 0)
> > gpiod_direction_output(pb->enable_gpio, 1);
> >
> > pb->power_supply = devm_regulator_get(>dev, "power");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 3/3] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction
On Sun, 14 Jan 2018, Wolfram Sang wrote:
> The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> fix this user (until a better, system-wide solution is in place).
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> ---
> Only build tested!
>
> drivers/video/backlight/pwm_bl.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied with Daniel and Simon's Acks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 1/4] dt-bindings: mfd: bd9571mwv: Document DDR Backup Mode properties
On Wed, 14 Mar 2018, Geert Uytterhoeven wrote: > Document the new optional properties related to DDR Backup Mode and > toggle/momentary power switches. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > --- > v2: > - Improve property description, > - Add properties for power switch type. > --- > Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 21 > + > 1 file changed, 21 insertions(+) Once Rob's comment has been handled: For my own reference: Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org> -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 10/16] mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE
On Thu, 18 Jan 2018, Masahiro Yamada wrote:
> The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT.
> No platform defines this flag any more. Remove.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> ---
>
> Changes in v3:
> - newly added
>
> Changes in v2: None
>
> drivers/mmc/host/tmio_mmc_core.c | 5 ++---
> include/linux/mfd/tmio.h | 1 -
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_core.c
> b/drivers/mmc/host/tmio_mmc_core.c
> index bdbff2d..7ad3433c 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -1075,10 +1075,9 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc,
> struct mmc_ios *ios)
> static int tmio_mmc_get_ro(struct mmc_host *mmc)
> {
> struct tmio_mmc_host *host = mmc_priv(mmc);
> - struct tmio_mmc_data *pdata = host->pdata;
>
> - return !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
> - (sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) &
> TMIO_STAT_WRPROTECT));
> + return !(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) &
> + TMIO_STAT_WRPROTECT);
> }
>
> static int tmio_multi_io_quirk(struct mmc_card *card,
> diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
> index 396a103c..91f9221 100644
> --- a/include/linux/mfd/tmio.h
> +++ b/include/linux/mfd/tmio.h
> @@ -36,7 +36,6 @@
> } while (0)
>
> /* tmio MMC platform flags */
> -#define TMIO_MMC_WRPROTECT_DISABLE BIT(0)
If it is truly not in use after this set:
Acked-by: Lee Jones <lee.jo...@linaro.org>
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH/RFC 1/5] dt-bindings: mfd: bd9571mwv: Document rohm,ddr-backup-power
On Fri, 13 Oct 2017, Geert Uytterhoeven wrote:
> Hi Lee,
>
> On Fri, Oct 13, 2017 at 10:55 AM, Lee Jones <lee.jo...@linaro.org> wrote:
> > On Tue, 10 Oct 2017, Geert Uytterhoeven wrote:
> >> Document the new optional "rohm,ddr-backup-power" property.
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> >> ---
> >> Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> >> b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> >> index 9ab216a851d5619b..7ea3f2db41d4e501 100644
> >> --- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> >> +++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> >> @@ -25,6 +25,12 @@ Required properties:
> >> Each child node is defined using the standard
> >> binding for regulators.
> >>
> >> +Optional properties:
> >> + - rohm,ddr-backup-power : Value to use for DDR-Backup Power. This
> >> controls
> >> + which DDR rails need to be kept powered when
> >> backup
> >> + mode is enabled, cfr. the KEEPON_DDR* bits in the
> >
> > Perhaps it's just me, but I'm confused by this line.
> >
> > Can you word it another way?
>
> I'll ttry... Let me think a bit about it...
I think it's just the "cfr" which is throwing me.
> >> + documentation for the "BKUP Mode Cnt" register.
> >> +
> >> Example:
> >>
> >> pmic: pmic@30 {
> >> @@ -36,6 +42,7 @@ Example:
> >> #interrupt-cells = <2>;
> >> gpio-controller;
> >> #gpio-cells = <2>;
> >> + rohm,ddr-backup-power = <15>;
> >
> > Can you explain what this means? Is it a mask, or does line 15 need
> > to be kept on? What is the range? Is 0 acceptable? Clarification
> > required please.
>
> It's a mask (OR of (in this case all four) needed KEEPON_DDR* bits).
> Unfortunately the datasheet is not publicly available.
>
> 0 is acceptable, but as the property is optional, you better just leave it
> out.
Would you mind reflecting that in the doc please?
Maybe a few more examples will help?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH/RFC 3/5] mfd: bd9571mwv: Allow DDR Backup Power register access
On Fri, 13 Oct 2017, Geert Uytterhoeven wrote: > Hi Lee, > > On Fri, Oct 13, 2017 at 10:58 AM, Lee Jones <lee.jo...@linaro.org> wrote: > > On Tue, 10 Oct 2017, Geert Uytterhoeven wrote: > > > >> Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which > >> is a.o. used to configure DDR Backup Power. > > > > a.o.? That's a new one on me. > > among(st) others Please just write that instead. :) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH/RFC 3/5] mfd: bd9571mwv: Allow DDR Backup Power register access
On Tue, 10 Oct 2017, Geert Uytterhoeven wrote: > Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which > is a.o. used to configure DDR Backup Power. a.o.? That's a new one on me. Please ensure commit logs are clear for *everyone* to read/understand by using descriptive and expanded (rather than shorten) terms. Code looks fine though, so once fixed: For my own reference: Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org> -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH/RFC 1/5] dt-bindings: mfd: bd9571mwv: Document rohm,ddr-backup-power
On Tue, 10 Oct 2017, Geert Uytterhoeven wrote:
> Document the new optional "rohm,ddr-backup-power" property.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
> Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> index 9ab216a851d5619b..7ea3f2db41d4e501 100644
> --- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> +++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> @@ -25,6 +25,12 @@ Required properties:
> Each child node is defined using the standard
> binding for regulators.
>
> +Optional properties:
> + - rohm,ddr-backup-power : Value to use for DDR-Backup Power. This controls
> + which DDR rails need to be kept powered when backup
> + mode is enabled, cfr. the KEEPON_DDR* bits in the
Perhaps it's just me, but I'm confused by this line.
Can you word it another way?
> + documentation for the "BKUP Mode Cnt" register.
> +
> Example:
>
> pmic: pmic@30 {
> @@ -36,6 +42,7 @@ Example:
> #interrupt-cells = <2>;
> gpio-controller;
> #gpio-cells = <2>;
> + rohm,ddr-backup-power = <15>;
Can you explain what this means? Is it a mask, or does line 15 need
to be kept on? What is the range? Is 0 acceptable? Clarification
required please.
> regulators {
> dvfs: dvfs {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] extcon: Split out extcon header file for consumer and provider device
On Fri, 29 Sep 2017, Chanwoo Choi wrote:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
>
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
> device driver. This header file contains the following APIs:
> : Register/unregister the notifier to catch the change of extcon device
> : Get the extcon device instance
> : Get the extcon device name
> : Get the state of each external connector
> : Get the property value of each external connector
> : Get the property capability of each external connector
>
> - extcon-provider.h includes the extcon API and data structure for extcon
> provider device driver. This header file contains the following APIs:
> : Include 'include/linux/extcon.h'
> : Allocate the memory for extcon device instance
> : Register/unregister extcon device
> : Set the state of each external connector
> : Set the property value of each external connector
> : Set the property capability of each external connector
>
> Cc: Felipe Balbi <ba...@kernel.org>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Sebastian Reichel <s...@kernel.org>
> Cc: Lee Jones <lee.jo...@linaro.org>
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
> drivers/extcon/extcon-adc-jack.c | 2 +-
> drivers/extcon/extcon-arizona.c | 2 +-
> drivers/extcon/extcon-axp288.c| 2 +-
> drivers/extcon/extcon-gpio.c | 2 +-
> drivers/extcon/extcon-intel-cht-wc.c | 2 +-
> drivers/extcon/extcon-intel-int3496.c | 2 +-
> drivers/extcon/extcon-max14577.c | 2 +-
> drivers/extcon/extcon-max3355.c | 2 +-
> drivers/extcon/extcon-max77693.c | 2 +-
> drivers/extcon/extcon-max77843.c | 2 +-
> drivers/extcon/extcon-max8997.c | 2 +-
> drivers/extcon/extcon-qcom-spmi-misc.c| 2 +-
> drivers/extcon/extcon-rt8973a.c | 2 +-
> drivers/extcon/extcon-sm5502.c| 2 +-
> drivers/extcon/extcon-usb-gpio.c | 2 +-
> drivers/extcon/extcon-usbc-cros-ec.c | 2 +-
> drivers/extcon/extcon.h | 2 +-
> drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
> drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c | 2 +-
> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +-
> drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 2 +-
> drivers/power/supply/qcom_smbb.c | 2 +-
> drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
> drivers/usb/phy/phy-tahvo.c | 2 +-
> drivers/usb/renesas_usbhs/common.h| 2 +-
> include/linux/extcon-provider.h | 142
> ++
> include/linux/extcon.h| 109 +---
> include/linux/mfd/palmas.h| 2 +-
Acked-by: Lee Jones <lee.jo...@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V3 1/2] mfd: Add ROHM BD9571MWV-M PMIC DT bindings
On Tue, 02 May 2017, Marek Vasut wrote: > Add DT bindings for the ROHM BD9571MWV-M PMIC. This PMIC has > the following features: > - multiple voltage monitors for 1V8, 2V5, 3V3 voltage rail > - one voltage regulator for DVFS > - two GPIOs > > Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > Cc: devicet...@vger.kernel.org > Cc: Rob Herring <r...@kernel.org> > Cc: Geert Uytterhoeven <geert+rene...@glider.be> > Cc: linux-renesas-soc@vger.kernel.org > Acked-by: Rob Herring <r...@kernel.org> > --- > V2: - Drop the compatible = "regulator-fixed" from the binding example, > it should not be there. > - List the VD09 regulator > V3: Replace bd9571@30 with pmic@30 > --- > .../devicetree/bindings/mfd/bd9571mwv.txt | 49 > ++ > 1 file changed, 49 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V4 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
On Mon, 17 Jul 2017, Marek Vasut wrote: > Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS > entry. The MFD part only specifies the regmap bits for the PMIC and > binds the subdevs together. > > Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > Cc: linux-ker...@vger.kernel.org > Cc: Geert Uytterhoeven <geert+rene...@glider.be> > Cc: Lee Jones <lee.jo...@linaro.org> > --- > V2: - Change BD9571MWV_AVS_VD09_VID0,1,2,3 to BD9571MWV_AVS_VD09_VID(n) > - Change BD9571MWV_AVS_DVFS_VID0,1,2,3 to BD9571MWV_AVS_DVFS_VID(n) > - Make the AVS_VD09 range RW, so it can be used by the regulator > driver for the VD09 regulator > - Report the regmap read return values when attempting to read ID > registers fails > V3: No change > V4: select REGMAP_IRQ > --- > MAINTAINERS | 11 ++ > drivers/mfd/Kconfig | 14 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/bd9571mwv.c | 230 > ++ > include/linux/mfd/bd9571mwv.h | 115 + > 5 files changed, 371 insertions(+) > create mode 100644 drivers/mfd/bd9571mwv.c > create mode 100644 include/linux/mfd/bd9571mwv.h Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V3 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
On Mon, 03 Jul 2017, Marek Vasut wrote: > On 07/03/2017 03:48 PM, Lee Jones wrote: > > On Mon, 03 Jul 2017, Marek Vasut wrote: > > > >> On 07/03/2017 01:55 PM, Lee Jones wrote: > >>> On Tue, 27 Jun 2017, Marek Vasut wrote: > >>> > >>>> On 05/02/2017 02:18 PM, Marek Vasut wrote: > >>>>> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS > >>>>> entry. The MFD part only specifies the regmap bits for the PMIC and > >>>>> binds the subdevs together. > >>>>> > >>>>> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > >>>>> Cc: linux-ker...@vger.kernel.org > >>>>> Cc: Geert Uytterhoeven <geert+rene...@glider.be> > >>>>> Cc: Lee Jones <lee.jo...@linaro.org> > >>>> > >>>> Lee, bump, do you plan to apply these patches anytime soon ? > >>> > >>> Looks like these were missed for some reason. > >> > >> Yes, they missed the previous merge window for some reason too, while > >> the rest of the patches from the set made it in. It'd be real nice if > >> they made it into the 4.13 ... > > > > They won't. The merge window is already open. > > > > You're looking at v4.14 now. > > So the rest of the patches made it into 4.12 and the MFD bit will make > it into 4.14 ... why precisely ? Mark applied the regulator patch before I was even aware the patch-set existed. The first patch you sent to me was on the 24th of April. I guess you forgot to Cc me on patches originating before that date? The v4.12 merge-window opened on the 30th of April, so your patch missed the deadline. Linus applied the GPIO patch to the v4.12 -rcs. He shouldn't have done that really, but justified it well enough. I could not apply the MFD patch at this time because RobH still had review comments outstanding. You sent v3 on the 2nd May whilst we were at -rc5. Since this is late in the cycle, there is a chance for patches to be applied, but that is not guaranteed. Unfortunately for you this also coincided with my vacation. You sent a bump 5 days before the merge window was about it open, which is way too late in the cycle to be applying patches. Unfortunately on this occasion, you were a victim of circumstance and poor timing. 1.5 cycles to have your patches applied is still perfectly acceptable. Especially after 3 revisions. > >>> I'll put them back on the pile for review. > >>> > >>> Please note that the merge window is currently open, so you are likely > >>> to experience a period of inactivity until -rc1 is released. > >> > >> I'd really appreciate it if these patches made it into the 4.13 release, > >> see above. > >> > >>>>> --- > >>>>> V2: - Change BD9571MWV_AVS_VD09_VID0,1,2,3 to BD9571MWV_AVS_VD09_VID(n) > >>>>> - Change BD9571MWV_AVS_DVFS_VID0,1,2,3 to BD9571MWV_AVS_DVFS_VID(n) > >>>>> - Make the AVS_VD09 range RW, so it can be used by the regulator > >>>>> driver for the VD09 regulator > >>>>> - Report the regmap read return values when attempting to read ID > >>>>> registers fails > >>>>> V3: No change > >>>>> --- > >>>>> MAINTAINERS | 11 ++ > >>>>> drivers/mfd/Kconfig | 13 +++ > >>>>> drivers/mfd/Makefile | 1 + > >>>>> drivers/mfd/bd9571mwv.c | 230 > >>>>> ++ > >>>>> include/linux/mfd/bd9571mwv.h | 115 + > >>>>> 5 files changed, 370 insertions(+) > >>>>> create mode 100644 drivers/mfd/bd9571mwv.c > >>>>> create mode 100644 include/linux/mfd/bd9571mwv.h > >>>>> > >>>>> diff --git a/MAINTAINERS b/MAINTAINERS > >>>>> index 2a9aa4be5846..9c30e6b00358 100644 > >>>>> --- a/MAINTAINERS > >>>>> +++ b/MAINTAINERS > >>>>> @@ -10942,6 +10942,17 @@ L: linux-ser...@vger.kernel.org > >>>>> S: Odd Fixes > >>>>> F: drivers/tty/serial/rp2.* > >>>>> > >>>>> +ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS > >>>>> +M: Marek Vasut <marek.vasut+rene...@gmail.com> > >>>>> +L: linux-ker...@vger.kernel.org > >>>>> +L: linux-renesas-soc@vger.kernel.org > >&
Re: [PATCH V3 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
On Mon, 03 Jul 2017, Marek Vasut wrote: > On 07/03/2017 01:55 PM, Lee Jones wrote: > > On Tue, 27 Jun 2017, Marek Vasut wrote: > > > >> On 05/02/2017 02:18 PM, Marek Vasut wrote: > >>> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS > >>> entry. The MFD part only specifies the regmap bits for the PMIC and > >>> binds the subdevs together. > >>> > >>> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > >>> Cc: linux-ker...@vger.kernel.org > >>> Cc: Geert Uytterhoeven <geert+rene...@glider.be> > >>> Cc: Lee Jones <lee.jo...@linaro.org> > >> > >> Lee, bump, do you plan to apply these patches anytime soon ? > > > > Looks like these were missed for some reason. > > Yes, they missed the previous merge window for some reason too, while > the rest of the patches from the set made it in. It'd be real nice if > they made it into the 4.13 ... They won't. The merge window is already open. You're looking at v4.14 now. > > I'll put them back on the pile for review. > > > > Please note that the merge window is currently open, so you are likely > > to experience a period of inactivity until -rc1 is released. > > I'd really appreciate it if these patches made it into the 4.13 release, > see above. > > >>> --- > >>> V2: - Change BD9571MWV_AVS_VD09_VID0,1,2,3 to BD9571MWV_AVS_VD09_VID(n) > >>> - Change BD9571MWV_AVS_DVFS_VID0,1,2,3 to BD9571MWV_AVS_DVFS_VID(n) > >>> - Make the AVS_VD09 range RW, so it can be used by the regulator > >>> driver for the VD09 regulator > >>> - Report the regmap read return values when attempting to read ID > >>> registers fails > >>> V3: No change > >>> --- > >>> MAINTAINERS | 11 ++ > >>> drivers/mfd/Kconfig | 13 +++ > >>> drivers/mfd/Makefile | 1 + > >>> drivers/mfd/bd9571mwv.c | 230 > >>> ++ > >>> include/linux/mfd/bd9571mwv.h | 115 + > >>> 5 files changed, 370 insertions(+) > >>> create mode 100644 drivers/mfd/bd9571mwv.c > >>> create mode 100644 include/linux/mfd/bd9571mwv.h > >>> > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >>> index 2a9aa4be5846..9c30e6b00358 100644 > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -10942,6 +10942,17 @@ L: linux-ser...@vger.kernel.org > >>> S: Odd Fixes > >>> F: drivers/tty/serial/rp2.* > >>> > >>> +ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS > >>> +M: Marek Vasut <marek.vasut+rene...@gmail.com> > >>> +L: linux-ker...@vger.kernel.org > >>> +L: linux-renesas-soc@vger.kernel.org > >>> +S: Supported > >>> +F: drivers/mfd/bd9571mwv.c > >>> +F: drivers/regulator/bd9571mwv-regulator.c > >>> +F: drivers/gpio/gpio-bd9571mwv.c > >>> +F: include/linux/mfd/bd9571mwv.h > >>> +F: Documentation/devicetree/bindings/mfd/bd9571mwv.txt > >>> + > >>> ROSE NETWORK LAYER > >>> M: Ralf Baechle <r...@linux-mips.org> > >>> L: linux-h...@vger.kernel.org > >>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > >>> index 3eb5c93595f6..6f4668ae28cc 100644 > >>> --- a/drivers/mfd/Kconfig > >>> +++ b/drivers/mfd/Kconfig > >>> @@ -133,6 +133,19 @@ config MFD_BCM590XX > >>> help > >>> Support for the BCM590xx PMUs from Broadcom > >>> > >>> +config MFD_BD9571MWV > >>> + tristate "ROHM BD9571MWV PMIC" > >>> + select MFD_CORE > >>> + select REGMAP_I2C > >>> + depends on I2C > >>> + help > >>> + Support for the ROHM BD9571MWV PMIC, which contains single > >>> + voltage regulator, voltage sampling units, GPIO block and > >>> + watchdog block. > >>> + > >>> + This driver can also be built as a module. If so, the module > >>> + will be called bd9571mwv. > >>> + > >>> config MFD_AC100 > >>> tristate "X-Powers AC100" > >>> select MFD_CORE > >>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > >>> index c16bf1ea0ea9..3cacc97
Re: [PATCH V3 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
On Tue, 27 Jun 2017, Marek Vasut wrote: > On 05/02/2017 02:18 PM, Marek Vasut wrote: > > Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS > > entry. The MFD part only specifies the regmap bits for the PMIC and > > binds the subdevs together. > > > > Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > > Cc: linux-ker...@vger.kernel.org > > Cc: Geert Uytterhoeven <geert+rene...@glider.be> > > Cc: Lee Jones <lee.jo...@linaro.org> > > Lee, bump, do you plan to apply these patches anytime soon ? Looks like these were missed for some reason. I'll put them back on the pile for review. Please note that the merge window is currently open, so you are likely to experience a period of inactivity until -rc1 is released. > > --- > > V2: - Change BD9571MWV_AVS_VD09_VID0,1,2,3 to BD9571MWV_AVS_VD09_VID(n) > > - Change BD9571MWV_AVS_DVFS_VID0,1,2,3 to BD9571MWV_AVS_DVFS_VID(n) > > - Make the AVS_VD09 range RW, so it can be used by the regulator > > driver for the VD09 regulator > > - Report the regmap read return values when attempting to read ID > > registers fails > > V3: No change > > --- > > MAINTAINERS | 11 ++ > > drivers/mfd/Kconfig | 13 +++ > > drivers/mfd/Makefile | 1 + > > drivers/mfd/bd9571mwv.c | 230 > > ++ > > include/linux/mfd/bd9571mwv.h | 115 + > > 5 files changed, 370 insertions(+) > > create mode 100644 drivers/mfd/bd9571mwv.c > > create mode 100644 include/linux/mfd/bd9571mwv.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 2a9aa4be5846..9c30e6b00358 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -10942,6 +10942,17 @@ L: linux-ser...@vger.kernel.org > > S: Odd Fixes > > F: drivers/tty/serial/rp2.* > > > > +ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS > > +M: Marek Vasut <marek.vasut+rene...@gmail.com> > > +L: linux-ker...@vger.kernel.org > > +L: linux-renesas-soc@vger.kernel.org > > +S: Supported > > +F: drivers/mfd/bd9571mwv.c > > +F: drivers/regulator/bd9571mwv-regulator.c > > +F: drivers/gpio/gpio-bd9571mwv.c > > +F: include/linux/mfd/bd9571mwv.h > > +F: Documentation/devicetree/bindings/mfd/bd9571mwv.txt > > + > > ROSE NETWORK LAYER > > M: Ralf Baechle <r...@linux-mips.org> > > L: linux-h...@vger.kernel.org > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > index 3eb5c93595f6..6f4668ae28cc 100644 > > --- a/drivers/mfd/Kconfig > > +++ b/drivers/mfd/Kconfig > > @@ -133,6 +133,19 @@ config MFD_BCM590XX > > help > > Support for the BCM590xx PMUs from Broadcom > > > > +config MFD_BD9571MWV > > + tristate "ROHM BD9571MWV PMIC" > > + select MFD_CORE > > + select REGMAP_I2C > > + depends on I2C > > + help > > + Support for the ROHM BD9571MWV PMIC, which contains single > > + voltage regulator, voltage sampling units, GPIO block and > > + watchdog block. > > + > > + This driver can also be built as a module. If so, the module > > + will be called bd9571mwv. > > + > > config MFD_AC100 > > tristate "X-Powers AC100" > > select MFD_CORE > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > index c16bf1ea0ea9..3cacc9748e13 100644 > > --- a/drivers/mfd/Makefile > > +++ b/drivers/mfd/Makefile > > @@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_ACT8945A)+= act8945a.o > > obj-$(CONFIG_MFD_SM501)+= sm501.o > > obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o > > obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o > > +obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o > > cros_ec_core-objs := cros_ec.o > > cros_ec_core-$(CONFIG_ACPI)+= cros_ec_acpi_gpe.o > > obj-$(CONFIG_MFD_CROS_EC) += cros_ec_core.o > > diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c > > new file mode 100644 > > index ..64e088dfe7b0 > > --- /dev/null > > +++ b/drivers/mfd/bd9571mwv.c > > @@ -0,0 +1,230 @@ > > +/* > > + * ROHM BD9571MWV-M MFD driver > > + * > > + * Copyright (C) 2017 Marek Vasut <marek.vasut+rene...@gmail.com> > > + * > > + * This program is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + * > > + * This
Re: [PATCH 4/7] mmc: use proper name for the R-Car SoC
On Mon, 29 May 2017, Ulf Hansson wrote: > On 28 May 2017 at 11:30, Wolfram Sang <wsa+rene...@sang-engineering.com> > wrote: > > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive > > text. > > > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > > Thanks, applied for next! > > For mfd, Lee, please tell if you have any issues me picking this via > my mmc tree. I don't, but it is normal procedure to wait for an Ack from all Maintainers involved before applying. ;) > > --- > > I suggest this trivial patch should be picked individually per susbsystem. > > > > drivers/mmc/host/renesas_sdhi_core.c | 2 +- > > include/linux/mfd/tmio.h | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c > > b/drivers/mmc/host/renesas_sdhi_core.c > > index 846ee1a8e5a675..397b3e29977ea8 100644 > > --- a/drivers/mmc/host/renesas_sdhi_core.c > > +++ b/drivers/mmc/host/renesas_sdhi_core.c > > @@ -130,7 +130,7 @@ static unsigned int renesas_sdhi_clk_update(struct > > tmio_mmc_host *host, > > unsigned int freq, diff, best_freq = 0, diff_min = ~0; > > int i, ret; > > > > - /* tested only on RCar Gen2+ currently; may work for others */ > > + /* tested only on R-Car Gen2+ currently; may work for others */ > > if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2)) > > return clk_get_rate(priv->clk); > > > > diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h > > index a1520d88ebf3a3..c83c16b931a886 100644 > > --- a/include/linux/mfd/tmio.h > > +++ b/include/linux/mfd/tmio.h > > @@ -66,7 +66,7 @@ > > */ > > #define TMIO_MMC_SDIO_IRQ (1 << 2) > > > > -/* Some features are only available or tested on RCar Gen2 or later */ > > +/* Some features are only available or tested on R-Car Gen2 or later */ > > #define TMIO_MMC_MIN_RCAR2 (1 << 3) > > > > /* > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RESEND][PATCH V2 3/4] gpio: Add ROHM BD9571MWV-M PMIC GPIO driver
On Fri, 28 Apr 2017, Linus Walleij wrote: > On Tue, Apr 25, 2017 at 8:32 PM, Marek Vasut <marek.va...@gmail.com> wrote: > > > Add driver for the GPIO block in the ROHM BD9571MWV-W MFD PMIC. > > This block is pretty trivial and supports setting GPIO direction > > as Input/Output and in case of Output, supports setting value. > > > > Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > > Cc: linux-g...@vger.kernel.org > > Cc: Geert Uytterhoeven <geert+rene...@glider.be> > > Cc: Linus Walleij <linus.wall...@linaro.org> > > Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > > --- > > V2: Use linux/gpio/driver.h instead of linux/gpio.h > > I applied this for v4.12 to bring down the number of deps in > v4.13. The guarding symbol makes it not compile until the MFD > patch is there, the MFD_BD9571MWV is unlikely to change, > and Marek will certainly go through with the driver submission. Works for me. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver
On Wed, 26 Apr 2017, Marek Vasut wrote: > On 04/26/2017 12:31 AM, Mark Brown wrote: > > On Tue, Apr 25, 2017 at 08:32:10PM +0200, Marek Vasut wrote: > >> Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. > >> This block supports three voltage monitors, VD18, VD25, VD33 for the > >> 1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the > >> DVFS rail. > > > > Please do not submit new versions of already applied patches, please > > submit incremental updates to the existing code. Modifying existing > > commits creates problems for other users building on top of those > > commits so it's best practice to only change pubished git commits if > > absolutely essential. > > I resubmitted this on Lee's request [1]. I think you misunderstood. Judging by what I've seen, I *assume* you want me to apply some patches which would not normally come under my jurisdiction. In order for this to happen, you need to send those patches directly to me (hyperlinks to some random representation of them somewhere on the internets will not do), complete with Acks from their associated Maintainer(s). This is why I asked you for a [RESEND]. I made no mention of resending patches which have already been applied into an upstream tree. There is seldom ever good reason to do this. Moving forward I need you to do the following: 1. Remove any patches from the set which have already been applied 2. Apply all Acks you have collected to the patches 3. Resend only the ones you wish applied, not forgetting to Cc me > [1] > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg13599.html -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V2 3/4] gpio: Add ROHM BD9571MWV-M PMIC GPIO driver
On Tue, 25 Apr 2017, Marek Vasut wrote: > On 04/25/2017 02:21 PM, Lee Jones wrote: > > On Tue, 25 Apr 2017, Marek Vasut wrote: > > > >> On 04/25/2017 11:32 AM, Linus Walleij wrote: > >>> On Mon, Apr 24, 2017 at 5:21 PM, Marek Vasut <marek.va...@gmail.com> > >>> wrote: > >>> > >>>> Add driver for the GPIO block in the ROHM BD9571MWV-W MFD PMIC. > >>>> This block is pretty trivial and supports setting GPIO direction > >>>> as Input/Output and in case of Output, supports setting value. > >>>> > >>>> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > >>>> Cc: linux-g...@vger.kernel.org > >>>> Cc: Geert Uytterhoeven <geert+rene...@glider.be> > >>>> Cc: Linus Walleij <linus.wall...@linaro.org> > >>>> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > >>>> --- > >>>> V2: Use linux/gpio/driver.h instead of linux/gpio.h > >>> > >>> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > >>> > >>> Are you merging this through MFD? > >> > >> I thought that was a question for Lee initially , IMO it'd make sense if > >> this went through one tree. > > > > Because your mailer is broken, I know have no idea which thread this > > mail belongs to. Please fix your mailer to reply 'threaded'. > > You just were not on CC for the whole series, just the MFD part, > probably that was the mistake, sorry. PW links below: Okay, understood. > https://patchwork.kernel.org/patch/9696589/ > https://patchwork.kernel.org/patch/9696591/ > https://patchwork.kernel.org/patch/9696597/ > https://patchwork.kernel.org/patch/9696593/ This is not the way we do business. If you want me to take them (and there is a suitable reason for me to do so i.e. a build-time dependency), then you're going to have to submit them again as [RESEND]s with me in Cc. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V2 3/4] gpio: Add ROHM BD9571MWV-M PMIC GPIO driver
On Tue, 25 Apr 2017, Marek Vasut wrote: > On 04/25/2017 11:32 AM, Linus Walleij wrote: > > On Mon, Apr 24, 2017 at 5:21 PM, Marek Vasut <marek.va...@gmail.com> wrote: > > > >> Add driver for the GPIO block in the ROHM BD9571MWV-W MFD PMIC. > >> This block is pretty trivial and supports setting GPIO direction > >> as Input/Output and in case of Output, supports setting value. > >> > >> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com> > >> Cc: linux-g...@vger.kernel.org > >> Cc: Geert Uytterhoeven <geert+rene...@glider.be> > >> Cc: Linus Walleij <linus.wall...@linaro.org> > >> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > >> --- > >> V2: Use linux/gpio/driver.h instead of linux/gpio.h > > > > Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > > > > Are you merging this through MFD? > > I thought that was a question for Lee initially , IMO it'd make sense if > this went through one tree. Because your mailer is broken, I know have no idea which thread this mail belongs to. Please fix your mailer to reply 'threaded'. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/4] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
On Sun, 16 Apr 2017, Marek Vasut wrote:
> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
> entry. The MFD part only specifies the regmap bits for the PMIC and
> binds the subdevs together.
>
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: linux-ker...@vger.kernel.org
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Lee Jones <lee.jo...@linaro.org>
> ---
> MAINTAINERS | 11 ++
> drivers/mfd/Kconfig | 13 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/bd9571mwv.c | 226
> ++
> include/linux/mfd/bd9571mwv.h | 120 ++
> 5 files changed, 371 insertions(+)
> create mode 100644 drivers/mfd/bd9571mwv.c
> create mode 100644 include/linux/mfd/bd9571mwv.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 892e958f6e50..90a96ee06ee4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10868,6 +10868,17 @@ L: linux-ser...@vger.kernel.org
> S: Odd Fixes
> F: drivers/tty/serial/rp2.*
>
> +ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS
> +M: Marek Vasut <marek.vasut+rene...@gmail.com>
> +L: linux-ker...@vger.kernel.org
> +L: linux-renesas-soc@vger.kernel.org
> +S: Supported
> +F: drivers/mfd/bd9571mwv.c
> +F: drivers/regulator/bd9571mwv-regulator.c
> +F: drivers/gpio/gpio-bd9571mwv.c
> +F: include/linux/mfd/bd9571mwv.h
> +F: Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> +
> ROSE NETWORK LAYER
> M: Ralf Baechle <r...@linux-mips.org>
> L: linux-h...@vger.kernel.org
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de68b5ba8741..fa1f41ef5332 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -133,6 +133,19 @@ config MFD_BCM590XX
> help
> Support for the BCM590xx PMUs from Broadcom
>
> +config MFD_BD9571MWV
> + tristate "ROHM BD9571MWV PMIC"
> + select MFD_CORE
> + select REGMAP_I2C
> + depends on I2C
> + help
> + Support for the ROHM BD9571MWV PMIC, which contains single
> + voltage regulator, voltage sampling units, GPIO block and
> + watchdog block.
> +
> + This driver can also be built as a module. If so, the module
> + will be called bd9571mwv.
> +
> config MFD_AC100
> tristate "X-Powers AC100"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index fa86dbe65e52..e2c82d2b108d 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> obj-$(CONFIG_MFD_SM501) += sm501.o
> obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
> obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
> +obj-$(CONFIG_MFD_BD9571MWV) += bd9571mwv.o
> cros_ec_core-objs:= cros_ec.o
> cros_ec_core-$(CONFIG_ACPI) += cros_ec_acpi_gpe.o
> obj-$(CONFIG_MFD_CROS_EC)+= cros_ec_core.o
> diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
> new file mode 100644
> index ..7382cdf308e8
> --- /dev/null
> +++ b/drivers/mfd/bd9571mwv.c
> @@ -0,0 +1,226 @@
> +/*
> + * ROHM BD9571MWV-M MFD driver
> + *
> + * Copyright (C) 2017 Marek Vasut <marek.vasut+rene...@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether expressed or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License version 2 for more details.
> + *
> + * Based on the TPS65086 driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static const struct mfd_cell bd9571mwv_cells[] = {
> + { .name = "bd9571mwv-regulator", },
> + { .name = "bd9571mwv-gpio", },
> +};
> +
> +static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
> + regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
> + regmap_reg_range(BD9571MWV_AVS_SET_MONI, BD9571MWV_AVS_DVFS_VID3),
> + regmap_reg_range(BD9571MWV_VD18_VID, BD9571MWV_VD33_VID),
> + regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_VINIT),
> + regmap_reg_range(BD9571MWV_DVFS_SETVMAX, BD9571MWV_DVFS_MONIVDAC),
> + regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
> + regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV
Re: [PATCH] backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction()
On Fri, 24 Mar 2017, Daniel Thompson wrote:
> On 24/03/17 16:42, Daniel Thompson wrote:
> > On 22/03/17 17:21, Geert Uytterhoeven wrote:
> > > Commit 7613c922315e308a ("backlight: pwm_bl: Move the checks for initial
> > > power state to a separate function") not just moved some code, but made
> > > slight changes in semantics.
> > >
> > > If a gpiochip doesn't implement the optional .get_direction() callback,
> > > gpiod_get_direction always returns -EINVAL, which is never equal to
> > > GPIOF_DIR_IN, leading to the GPIO not being configured for output.
> > >
> > > To avoid this, invert the test and check for not GPIOF_DIR_OUT instead,
> > > like the original code did.
> > >
> > > This restores the display on r8a7740/armadillo.
> > >
> > > Fixes: 7613c922315e308a ("backlight: pwm_bl: Move the checks for
> > > initial power state to a separate function")
> > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> >
> > Acked-by: Daniel Thommpson <daniel.thomp...@linaro.org>
>
> Actually, it would be better if there only one m...
>
> Acked-by: Daniel Thompson <daniel.thomp...@linaro.org>
You probably don't want to be typing out your Acks manually every
time. Can you set a key combination in your editor?
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > b/drivers/video/backlight/pwm_bl.c
> > > index d7efcb632f7d9dde..002f1ce22bd02032 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -297,14 +297,15 @@ static int pwm_backlight_probe(struct
> > > platform_device *pdev)
> > > }
> > >
> > > /*
> > > - * If the GPIO is configured as input, change the direction to
> > > output
> > > - * and set the GPIO as active.
> > > + * If the GPIO is not known to be already configured as output, that
> > > + * is, if gpiod_get_direction returns either GPIOF_DIR_IN or
> > > -EINVAL,
> > > + * change the direction to output and set the GPIO as active.
> > > * Do not force the GPIO to active when it was already output as it
> > > * could cause backlight flickering or we would enable the
> > > backlight too
> > > * early. Leave the decision of the initial backlight state for
> > > later.
> > > */
> > > if (pb->enable_gpio &&
> > > -gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN)
> > > +gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> > > gpiod_direction_output(pb->enable_gpio, 1);
> > >
> > > pb->power_supply = devm_regulator_get(>dev, "power");
> > >
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
