| Message ID | 3b05ca98a671a762013c312f8b70543402ee7556.1527669443.git.matti.vaittinen@fi.rohmeurope.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > Document devicetree bindings for ROHM BD71837 PMIC MFD. > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> > --- > .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 52 ++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt > > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt > new file mode 100644 > index 000000000000..bbc46d38b162 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt > @@ -0,0 +1,52 @@ > +* ROHM BD71837 Power Management Integrated Circuit bindings > + > +BD71837MWV is a programmable Power Management IC for powering single-core, > +dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for > +low BOM cost and compact solution footprint. It integrates 8 Buck > +egulators and 7 LDO’s to provide all the power rails required by the SoC and > +the commonly used peripherals. > + > +Required properties: > + - compatible : Should be "rohm,bd71837". > + - reg : I2C slave address. > + - interrupt-parent : Phandle to the parent interrupt controller. > + - interrupts : The interrupt line the device is connected to. > + - interrupt-controller : Marks the device node as an interrupt controller. What sub blocks have interrupts? > + - #interrupt-cells : The number of cells to describe an IRQ, should be 1 or 2. > + The first cell is the IRQ number. > + The second cell if present is the flags, encoded as trigger > + masks from ../interrupt-controller/interrupts.txt. > + - regulators: : List of child nodes that specify the regulators > + Please see ../regulator/rohm,bd71837-regulator.txt > + - clock: : Please see ../clock/rohm,bd71837-clock.txt > + > +Example: > + > + pmic: bd71837@4b { Node names should be generic ideally. So "pmic@4b" > + compatible = "rohm,bd71837"; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x4b>; > + interrupt-parent = <&gpio1>; > + interrupts = <29 GPIO_ACTIVE_LOW>; > + interrupt-names = "irq"; > + #interrupt-cells = <1>; > + interrupt-controller; > + > + regulators { > + buck1: BUCK1 { > + regulator-name = "buck1"; > + regulator-min-microvolt = <700000>; > + regulator-max-microvolt = <1300000>; > + regulator-boot-on; > + regulator-ramp-delay = <1250>; > + }; > + ... > + }; > + clk: bd71837-32k-out { clock-controller { > + compatible = "rohm,bd71837-clk"; > + #clock-cells = <0>; > + clock-frequency = <32768>; Can this be anything else? > + clock-output-names = "bd71837-32k-out"; > + }; > + }; > -- > 2.14.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Rob, Thanks for the review! On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > > + - interrupts : The interrupt line the device is connected to. > > + - interrupt-controller : Marks the device node as an interrupt controller. > > What sub blocks have interrupts? The PMIC can generate interrupts from events which cause it to reset. Eg, irq from watchdog line change, power button pushes, reset request via register interface etc. I don't know any generic handling for these interrupts. In "normal" use-case this PMIC is powering the processor where driver is running and I do not see reasonable handling because power-reset is going to follow the irq. This IRQ might be relevant if use for PMIC is such that it is not powering the processor where the driver is runninng. Then the controlling processor can get the notification that chips powered by PMIC are resetting. But handling for this must be use-case specific, right? So in short - none of the current sub-devices use the IRQs - they are there for specific use-cases which some boards may implement. Any suggestions how to document the available interrupts? (power button line, sw reset etc). My current assumption has been that one who is interested in using these irqs should really also see the data-sheet for IRQs. But I admit that documenting available interrupts here would be helpful. I will just cook up some explanation and send it as a patch if no suggestions on how to document those. Patches 3/6 and 6/6 from the series were already applied to Mark's tree. So how should I send further patches? Should I still send the whole series (including already applied patches 3/6 and 6/6) or only the ones I change? > > +Example: > > + > > + pmic: bd71837@4b { > > Node names should be generic ideally. So "pmic@4b" I'll change that. > > + clk: bd71837-32k-out { > > clock-controller { And I'll change that too. > > > + compatible = "rohm,bd71837-clk"; > > + #clock-cells = <0>; > > + clock-frequency = <32768>; > > Can this be anything else? Not so that I know. Frequency is fixed. Is there a problem with this? Br, Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > Hello Rob, > > Thanks for the review! > > On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > > > + - interrupts : The interrupt line the device is connected to. > > > + - interrupt-controller : Marks the device node as an interrupt controller. > > > > What sub blocks have interrupts? > > The PMIC can generate interrupts from events which cause it to reset. > Eg, irq from watchdog line change, power button pushes, reset request > via register interface etc. I don't know any generic handling for these > interrupts. In "normal" use-case this PMIC is powering the processor > where driver is running and I do not see reasonable handling because > power-reset is going to follow the irq. > Oh, but when reading this I understand that the interrupt-controller property should at least be optional. Br, Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: >> Hello Rob, >> >> Thanks for the review! >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. >> > > + - interrupts : The interrupt line the device is connected to. >> > > + - interrupt-controller : Marks the device node as an interrupt controller. >> > >> > What sub blocks have interrupts? >> >> The PMIC can generate interrupts from events which cause it to reset. >> Eg, irq from watchdog line change, power button pushes, reset request >> via register interface etc. I don't know any generic handling for these >> interrupts. In "normal" use-case this PMIC is powering the processor >> where driver is running and I do not see reasonable handling because >> power-reset is going to follow the irq. >> > > Oh, but when reading this I understand that the interrupt-controller > property should at least be optional. I don't think it should. The h/w either has an interrupt controller or it doesn't. My concern is you added it but nothing uses it which tells me your binding is incomplete. I'd rather see complete bindings even if you don't have drivers. For example, as-is, there's not really any need for the clocks child node. You can just make the parent a clock provider. But we need a complete picture of the h/w to make that determination. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Rob Herring (2018-05-31 07:07:24) > On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > <mazziesaccount@gmail.com> wrote: > > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > >> Hello Rob, > >> > >> Thanks for the review! > >> > >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > >> > > + - interrupts : The interrupt line the device is connected to. > >> > > + - interrupt-controller : Marks the device node as an interrupt controller. > >> > > >> > What sub blocks have interrupts? > >> > >> The PMIC can generate interrupts from events which cause it to reset. > >> Eg, irq from watchdog line change, power button pushes, reset request > >> via register interface etc. I don't know any generic handling for these > >> interrupts. In "normal" use-case this PMIC is powering the processor > >> where driver is running and I do not see reasonable handling because > >> power-reset is going to follow the irq. > >> > > > > Oh, but when reading this I understand that the interrupt-controller > > property should at least be optional. > > I don't think it should. The h/w either has an interrupt controller or > it doesn't. My concern is you added it but nothing uses it which tells > me your binding is incomplete. I'd rather see complete bindings even > if you don't have drivers. For example, as-is, there's not really any > need for the clocks child node. You can just make the parent a clock > provider. But we need a complete picture of the h/w to make that > determination. > I don't see a reason to have the clk subnode either. -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: > On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > <mazziesaccount@gmail.com> wrote: > > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > >> > > + - interrupts : The interrupt line the device is connected to. > >> > > + - interrupt-controller : Marks the device node as an interrupt controller. > >> > > >> > What sub blocks have interrupts? > >> > >> The PMIC can generate interrupts from events which cause it to reset. > >> Eg, irq from watchdog line change, power button pushes, reset request > >> via register interface etc. I don't know any generic handling for these > >> interrupts. In "normal" use-case this PMIC is powering the processor > >> where driver is running and I do not see reasonable handling because > >> power-reset is going to follow the irq. > >> > > > > Oh, but when reading this I understand that the interrupt-controller > > property should at least be optional. > > I don't think it should. The h/w either has an interrupt controller or > it doesn't. I hope this explains why I did this interrupt controller - please tell me if this is legitimate use-case and what you think of following: +Optional properties: + - interrupt-controller : Marks the device node as an interrupt controller. + BD71837MWV can report different power state change + events to other devices. Different events can be seen + as separate BD71837 domain interrupts. + - #interrupt-cells : The number of cells to describe an IRQ should be 1. + The first cell is the IRQ number. + masks from ../interrupt-controller/interrupts.txt. > My concern is you added it but nothing uses it which tells > me your binding is incomplete. I'd rather see complete bindings even > if you don't have drivers. So this makes me wonder if my use-case for interrupt controller is valid. I thought making this PMIC as interrupt controller is a nice way of hiding the irq register and i2c access from other potential drivers using these interrupts. But as I don't know what could be the potential user for these irqs, I don't know how to complete binding. This is why I also thought of making this optional, so that the potential for using the interrupts would be there but it was not required when interrupts are not needed. > For example, as-is, there's not really any > need for the clocks child node. You can just make the parent a clock > provider. This sounds correct. I just lack of knowledge on how to handle clocks in "standard way" using the clock framework and this was a result of my first attempt. (Funny, I have written clk / synchronization drivers for work in the past but still I have no idea on how to do this in "standard way"). > But we need a complete picture of the h/w to make that > determination. My attempt is to create generic driver for this PMIC. I would rather not limit it's use to any particular board/soc. The example binding is based on my test environment where I simply connected this PMIC break out board to beagle bone black. (I do also have a test board where i.MX8 and peripherials are powered by this PMIC but I rather not limit this driver to such single setup. Besides the linux running on that board is not 'standard') The PMIC itself just has this 32.768 KHz clock output. Clock can be enabled/disabled via register interface. I think this is intended to be used for RTC but I thought this driver does not need to care about that. I thought it is just a good idea to provide control via clk subsystem and to not make assumptions on use-cases in this driver. Best Regards Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 31, 2018 at 07:57:53AM -0700, Stephen Boyd wrote: > Quoting Rob Herring (2018-05-31 07:07:24) > > On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > > <mazziesaccount@gmail.com> wrote: > > > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > > >> Hello Rob, > > >> > > >> Thanks for the review! > > >> > > >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > > >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > > >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > > >> > > + - interrupts : The interrupt line the device is connected to. > > >> > > + - interrupt-controller : Marks the device node as an interrupt controller. > > >> > > > >> > What sub blocks have interrupts? > > >> > > >> The PMIC can generate interrupts from events which cause it to reset. > > >> Eg, irq from watchdog line change, power button pushes, reset request > > >> via register interface etc. I don't know any generic handling for these > > >> interrupts. In "normal" use-case this PMIC is powering the processor > > >> where driver is running and I do not see reasonable handling because > > >> power-reset is going to follow the irq. > > >> > > > > > > Oh, but when reading this I understand that the interrupt-controller > > > property should at least be optional. > > > > I don't think it should. The h/w either has an interrupt controller or > > it doesn't. My concern is you added it but nothing uses it which tells > > me your binding is incomplete. I'd rather see complete bindings even > > if you don't have drivers. For example, as-is, there's not really any > > need for the clocks child node. You can just make the parent a clock > > provider. But we need a complete picture of the h/w to make that > > determination. > > > > I don't see a reason to have the clk subnode either. After some pondering - do you mean I could: 1. remove clk binfing document and clk node. 2. add clock-output-names etc to pmic node (and describe them in pmic node binding document) 3. use parent DT node in clk driver and do something like: if (parent->of_node) ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get, hw); 4. remove the clkdev I will cook new set of patches with all suggested changes but it may be I don't get it ready for posting untill next week. Br, Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen >> <mazziesaccount@gmail.com> wrote: >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. >> >> > > + - interrupts : The interrupt line the device is connected to. >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller. >> >> > >> >> > What sub blocks have interrupts? >> >> >> >> The PMIC can generate interrupts from events which cause it to reset. >> >> Eg, irq from watchdog line change, power button pushes, reset request >> >> via register interface etc. I don't know any generic handling for these >> >> interrupts. In "normal" use-case this PMIC is powering the processor >> >> where driver is running and I do not see reasonable handling because >> >> power-reset is going to follow the irq. >> >> >> > >> > Oh, but when reading this I understand that the interrupt-controller >> > property should at least be optional. >> >> I don't think it should. The h/w either has an interrupt controller or >> it doesn't. > > I hope this explains why I did this interrupt controller - please tell > me if this is legitimate use-case and what you think of following: > > +Optional properties: > + - interrupt-controller : Marks the device node as an interrupt controller. > + BD71837MWV can report different power state change > + events to other devices. Different events can be seen > + as separate BD71837 domain interrupts. To what other devices? > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. > + The first cell is the IRQ number. > + masks from ../interrupt-controller/interrupts.txt. I'm still not clear. Generally in a PMIC, you'd define an interrupt controller when there's a common set of registers to manage sub-block interrupts (typical mask/unmask, ack regs) and the subblocks themselves have control of masking/unmasking interrupts. If there's not a need to have these 2 levels of interrupt handling, then you don't really need to define an interrupt controller. > >> My concern is you added it but nothing uses it which tells >> me your binding is incomplete. I'd rather see complete bindings even >> if you don't have drivers. > > So this makes me wonder if my use-case for interrupt controller is > valid. I thought making this PMIC as interrupt controller is a nice way > of hiding the irq register and i2c access from other potential drivers > using these interrupts. But as I don't know what could be the potential > user for these irqs, I don't know how to complete binding. This is why I > also thought of making this optional, so that the potential for using > the interrupts would be there but it was not required when interrupts > are not needed. The only drivers getting these interrupts would be drivers for this PMIC. Interrupts are handled by the driver owning the h/w that generated the interrupt. I think that is the disconnect here. Take a power button. We don't create a generic power button interrupt and then have some generic power button interrupt handler. We have a handler for specifically for that device and then it generates a power button press event. >> For example, as-is, there's not really any >> need for the clocks child node. You can just make the parent a clock >> provider. > > This sounds correct. I just lack of knowledge on how to handle clocks > in "standard way" using the clock framework and this was a result of > my first attempt. (Funny, I have written clk / synchronization drivers > for work in the past but still I have no idea on how to do this in > "standard way"). > >> But we need a complete picture of the h/w to make that >> determination. > > My attempt is to create generic driver for this PMIC. I would rather not > limit it's use to any particular board/soc. The example binding is based > on my test environment where I simply connected this PMIC break out > board to beagle bone black. (I do also have a test board where i.MX8 and > peripherials are powered by this PMIC but I rather not limit this driver > to such single setup. Besides the linux running on that board is not > 'standard') That's how we design all the PMIC drivers. All the PMIC functions should be exposed thru standard class APIs. Though many PMICs are pretty tightly coupled to particular SoCs either by design or just there's not a lot of boards to create any sort of matrix of combinations. > The PMIC itself just has this 32.768 KHz clock output. Clock can be > enabled/disabled via register interface. I think this is intended to be > used for RTC but I thought this driver does not need to care about that. > I thought it is just a good idea to provide control via clk subsystem > and to not make assumptions on use-cases in this driver. Sure that is fine. No one is saying you shouldn't do that. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Matti Vaittinen (2018-06-01 03:51:05) > On Thu, May 31, 2018 at 07:57:53AM -0700, Stephen Boyd wrote: > > Quoting Rob Herring (2018-05-31 07:07:24) > > > > > > I don't think it should. The h/w either has an interrupt controller or > > > it doesn't. My concern is you added it but nothing uses it which tells > > > me your binding is incomplete. I'd rather see complete bindings even > > > if you don't have drivers. For example, as-is, there's not really any > > > need for the clocks child node. You can just make the parent a clock > > > provider. But we need a complete picture of the h/w to make that > > > determination. > > > > > > > I don't see a reason to have the clk subnode either. > > After some pondering - do you mean I could: > 1. remove clk binfing document and clk node. > 2. add clock-output-names etc to pmic node (and describe them in pmic > node binding document) > 3. use parent DT node in clk driver and do something like: > if (parent->of_node) > ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get, > hw); > 4. remove the clkdev > This sounds ok to me. As Rob said, a more complete picture of the hardware would make this easier. -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote: > On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen > <mazziesaccount@gmail.com> wrote: > > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: > >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > >> <mazziesaccount@gmail.com> wrote: > >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > >> >> > > + - interrupts : The interrupt line the device is connected to. > >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller. > >> >> > > >> >> > What sub blocks have interrupts? > >> >> > >> >> The PMIC can generate interrupts from events which cause it to reset. > >> >> Eg, irq from watchdog line change, power button pushes, reset request > >> >> via register interface etc. I don't know any generic handling for these > >> >> interrupts. In "normal" use-case this PMIC is powering the processor > >> >> where driver is running and I do not see reasonable handling because > >> >> power-reset is going to follow the irq. > >> >> > >> > > >> > Oh, but when reading this I understand that the interrupt-controller > >> > property should at least be optional. > >> > >> I don't think it should. The h/w either has an interrupt controller or > >> it doesn't. > > > > I hope this explains why I did this interrupt controller - please tell > > me if this is legitimate use-case and what you think of following: > > > > +Optional properties: > > + - interrupt-controller : Marks the device node as an interrupt controller. > > + BD71837MWV can report different power state change > > + events to other devices. Different events can be seen > > + as separate BD71837 domain interrupts. > > To what other devices? Would it be better if I wrote "other drivers" instead? I think I've seen examples where MFD driver is just providing the interrupts for other drivers - like power-button input driver. Currently I have no such "irq consumer" drivers written. Still I would like to expose these interrupts so that they are ready for using if any platform using PMIC needs them. I think there are other similar drivers in tree. For example TPS6591x driver seems to be doing this. (Has MFD driver exposing the interrupts but no driver handling those). Maybe explanation like this would help: "The BD71837 driver only provides the infrastructure for the IRQs. The users can write his own driver to convert the IRQ into the event they wish. The IRQ can be used with the standard request_irq/enable_irq/disable_irq API inside the kernel." (I found this text from NXP forums and ruthlessly copied and modified it over here) If this is not feasible, then I will remove the irq handling from MFD (or leave code there but remove the binding information?) as I don't know what the irq handles should do in generic case. > > > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. > > + The first cell is the IRQ number. > > + masks from ../interrupt-controller/interrupts.txt. Sorry this "masks from ../interrupt-controller/interrupts.txt." was accidentally pasted here. I should have deleted it. > I'm still not clear. Generally in a PMIC, you'd define an interrupt > controller when there's a common set of registers to manage sub-block > interrupts (typical mask/unmask, ack regs) and the subblocks > themselves have control of masking/unmasking interrupts. If there's > not a need to have these 2 levels of interrupt handling, then you > don't really need to define an interrupt controller. And to clarify - the PMIC can generate irq via one irq line. This is typical ACTIVE_LOW irq with 8 bit "write 1 to clear" status register and 8 bit mask register. The role of interrupt-controller code here is just to allow these 8 irq reasons to be seen as individual BD71837 domain interrupts. I just don't have the driver(s) for handling these interrupts. > >> My concern is you added it but nothing uses it which tells > >> me your binding is incomplete. I'd rather see complete bindings even > >> if you don't have drivers. > > > > So this makes me wonder if my use-case for interrupt controller is > > valid. I thought making this PMIC as interrupt controller is a nice way > > of hiding the irq register and i2c access from other potential drivers > > using these interrupts. But as I don't know what could be the potential > > user for these irqs, I don't know how to complete binding. This is why I > > also thought of making this optional, so that the potential for using > > the interrupts would be there but it was not required when interrupts > > are not needed. > > The only drivers getting these interrupts would be drivers for this > PMIC. Interrupts are handled by the driver owning the h/w that > generated the interrupt. I think that is the disconnect here. > > Take a power button. We don't create a generic power button interrupt > and then have some generic power button interrupt handler. We have a > handler for specifically for that device and then it generates a power > button press event. I think I understand this. Here we also have a 'power button' interrupt from PMIC (as one of the interrupts) here. But what happens when button is pressed depends on PMIC configuration. I guess we might want a power button driver here - and this power button driver might be correct user for the irq. So are you stating that I should write the power button driver (or some other "IRQ consumer") before adding the interrupt-controller property to bindings for MFD? Or should I just somehow state that irq X in BD71837 is a "power button short push" event and power button driver should be the consumer for it? Rest of the interrupts are not so obvious. I have no idea how I should handle rest of the interrupts. Those are interrupts which cause the PMIC to reset and cut the powers from most of the regulators too. I can easily think setup where one processor is controlling PMIC which powers for the other processor. And getting IRQ if for example watchdog reset the other processor would probably be very usefull. But doing any 'de-facto' handler for this is hard. Only generally usefull thing would be notifying the user-space but I don't think I should invent any new kernelspace - userspace interfaces for this. I believe that when such are needed those should be implemented by ones knowing the platform. So please bear with me but do you mean I should a) document what conditions generate which IRQ or b) should I tell what kind of driver is needed for handling the IRQs or c) should I first write code using IRQs before addinf MFD binding? a) I can do. b) I think I can't do this for most of the irqs as in normal use-case the processor won't catch these as it is going to be powered down. c) I might be able to do this for power button IRQ but it might not be what user wants in the end. > >> My concern is you added it but nothing uses it which tells > >> me your binding is incomplete. I'd rather see complete bindings even > >> if you don't have drivers. Can you please tell if I misunderstood this? Br, Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote: >> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen >> <mazziesaccount@gmail.com> wrote: >> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: >> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen >> >> <mazziesaccount@gmail.com> wrote: >> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: >> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: >> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: >> >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. >> >> >> > > + - interrupts : The interrupt line the device is connected to. >> >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller. >> >> >> > >> >> >> > What sub blocks have interrupts? >> >> >> >> >> >> The PMIC can generate interrupts from events which cause it to reset. >> >> >> Eg, irq from watchdog line change, power button pushes, reset request >> >> >> via register interface etc. I don't know any generic handling for these >> >> >> interrupts. In "normal" use-case this PMIC is powering the processor >> >> >> where driver is running and I do not see reasonable handling because >> >> >> power-reset is going to follow the irq. >> >> >> >> >> > >> >> > Oh, but when reading this I understand that the interrupt-controller >> >> > property should at least be optional. >> >> >> >> I don't think it should. The h/w either has an interrupt controller or >> >> it doesn't. >> > >> > I hope this explains why I did this interrupt controller - please tell >> > me if this is legitimate use-case and what you think of following: >> > >> > +Optional properties: >> > + - interrupt-controller : Marks the device node as an interrupt controller. >> > + BD71837MWV can report different power state change >> > + events to other devices. Different events can be seen >> > + as separate BD71837 domain interrupts. >> >> To what other devices? > > Would it be better if I wrote "other drivers" instead? I think I've seen > examples where MFD driver is just providing the interrupts for other > drivers - like power-button input driver. Currently I have no such "irq > consumer" drivers written. Still I would like to expose these interrupts > so that they are ready for using if any platform using PMIC needs them. No, worse. Interrupt binding describes interrupt connections between a controller and devices (which could be sub-blocks in a device), not to drivers. I'm just curious as to what sub-blocks/devices there are. You don't have to have a driver (yet) to define the devices. > > I think there are other similar drivers in tree. For example TPS6591x > driver seems to be doing this. (Has MFD driver exposing the interrupts > but no driver handling those). Maybe explanation like this would help: > > "The BD71837 driver only provides the infrastructure for the IRQs. The > users can write his own driver to convert the IRQ into the event they > wish. The IRQ can be used with the standard > request_irq/enable_irq/disable_irq API inside the kernel." (I found this > text from NXP forums and ruthlessly copied and modified it over here) That's all OS details that have nothing to do with the binding. The binding describes the h/w. > If this is not feasible, then I will remove the irq handling from MFD > (or leave code there but remove the binding information?) as I don't > know what the irq handles should do in generic case. I don't understand what you mean by generic. An IRQ has to be wired to something. The only generic IRQs are GPIOs. >> > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. >> > + The first cell is the IRQ number. >> > + masks from ../interrupt-controller/interrupts.txt. > > Sorry this "masks from ../interrupt-controller/interrupts.txt." was > accidentally pasted here. I should have deleted it. > >> I'm still not clear. Generally in a PMIC, you'd define an interrupt >> controller when there's a common set of registers to manage sub-block >> interrupts (typical mask/unmask, ack regs) and the subblocks >> themselves have control of masking/unmasking interrupts. If there's >> not a need to have these 2 levels of interrupt handling, then you >> don't really need to define an interrupt controller. > > And to clarify - the PMIC can generate irq via one irq line. This is > typical ACTIVE_LOW irq with 8 bit "write 1 to clear" status register and > 8 bit mask register. The role of interrupt-controller code here is just > to allow these 8 irq reasons to be seen as individual BD71837 domain > interrupts. I just don't have the driver(s) for handling these > interrupts. If what I'm asking for above is still not clear, what are the 8 bits defined as or what are those 8 lines connected to? > >> >> My concern is you added it but nothing uses it which tells >> >> me your binding is incomplete. I'd rather see complete bindings even >> >> if you don't have drivers. >> > >> > So this makes me wonder if my use-case for interrupt controller is >> > valid. I thought making this PMIC as interrupt controller is a nice way >> > of hiding the irq register and i2c access from other potential drivers >> > using these interrupts. But as I don't know what could be the potential >> > user for these irqs, I don't know how to complete binding. This is why I >> > also thought of making this optional, so that the potential for using >> > the interrupts would be there but it was not required when interrupts >> > are not needed. >> >> The only drivers getting these interrupts would be drivers for this >> PMIC. Interrupts are handled by the driver owning the h/w that >> generated the interrupt. I think that is the disconnect here. >> >> Take a power button. We don't create a generic power button interrupt >> and then have some generic power button interrupt handler. We have a >> handler for specifically for that device and then it generates a power >> button press event. > > I think I understand this. Here we also have a 'power button' interrupt > from PMIC (as one of the interrupts) here. But what happens when button > is pressed depends on PMIC configuration. I guess we might want a power > button driver here - and this power button driver might be correct user > for the irq. So are you stating that I should write the power button > driver (or some other "IRQ consumer") before adding the > interrupt-controller property to bindings for MFD? No. Bindings come before drivers. > Or should I just > somehow state that irq X in BD71837 is a "power button short push" > event and power button driver should be the consumer for it? Yes, at least, but who is the consumer is an OS detail that is not relevant to the binding. Ideally, you would describe the node with the interrupts property for "irq X". > Rest of the interrupts are not so obvious. I have no idea how I should > handle rest of the interrupts. Those are interrupts which cause the PMIC > to reset and cut the powers from most of the regulators too. I can > easily think setup where one processor is controlling PMIC which powers > for the other processor. And getting IRQ if for example watchdog reset > the other processor would probably be very usefull. But doing any > 'de-facto' handler for this is hard. Only generally usefull thing would > be notifying the user-space but I don't think I should invent any new > kernelspace - userspace interfaces for this. I believe that when such > are needed those should be implemented by ones knowing the platform. Don't think about the OS or driver details. Think about sub-blocks of the hardware and the connections between them (like irqs) and to board that need to be described in DT. If you can't describe that, then you just probably shouldn't have sub-nodes in DT (ever). Though adding later is easier than trying to remove them. > > So please bear with me but do you mean I should > a) document what conditions generate which IRQ > or > b) should I tell what kind of driver is needed for handling the IRQs > or > c) should I first write code using IRQs before addinf MFD binding? A. > a) I can do. > b) I think I can't do this for most of the irqs as in normal use-case > the processor won't catch these as it is going to be powered down. > c) I might be able to do this for power button IRQ but it might not be > what user wants in the end. > >> >> My concern is you added it but nothing uses it which tells >> >> me your binding is incomplete. I'd rather see complete bindings even >> >> if you don't have drivers. > > Can you please tell if I misunderstood this? > > Br, > Matti Vaittinen > -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 05, 2018 at 10:46:14AM -0500, Rob Herring wrote: > On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen > <mazziesaccount@gmail.com> wrote: > > On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote: > >> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen > >> <mazziesaccount@gmail.com> wrote: > >> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: > >> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > >> >> <mazziesaccount@gmail.com> wrote: > >> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > >> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > >> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > >> >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. > >> >> >> > > + - interrupts : The interrupt line the device is connected to. > >> >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller. > >> >> >> > > >> >> >> > What sub blocks have interrupts? > >> >> >> > >> >> >> The PMIC can generate interrupts from events which cause it to reset. > >> >> >> Eg, irq from watchdog line change, power button pushes, reset request > >> >> >> via register interface etc. I don't know any generic handling for these > >> >> >> interrupts. In "normal" use-case this PMIC is powering the processor > >> >> >> where driver is running and I do not see reasonable handling because > >> >> >> power-reset is going to follow the irq. > >> >> >> > >> >> > > >> >> > Oh, but when reading this I understand that the interrupt-controller > >> >> > property should at least be optional. > >> >> > >> >> I don't think it should. The h/w either has an interrupt controller or > >> >> it doesn't. > >> > > >> > I hope this explains why I did this interrupt controller - please tell > >> > me if this is legitimate use-case and what you think of following: > >> > > >> > +Optional properties: > >> > + - interrupt-controller : Marks the device node as an interrupt controller. > >> > + BD71837MWV can report different power state change > >> > + events to other devices. Different events can be seen > >> > + as separate BD71837 domain interrupts. > >> > >> To what other devices? > > > > Would it be better if I wrote "other drivers" instead? I think I've seen > > examples where MFD driver is just providing the interrupts for other > > drivers - like power-button input driver. Currently I have no such "irq > > consumer" drivers written. Still I would like to expose these interrupts > > so that they are ready for using if any platform using PMIC needs them. > > No, worse. Interrupt binding describes interrupt connections between a > controller and devices (which could be sub-blocks in a device), not to > drivers. Ok. > I'm just curious as to what sub-blocks/devices there are. You don't > have to have a driver (yet) to define the devices. Right. I should have done this from the start. I just thought everyone is busy with other things and pushing people to read data sheets might be considered as lazines. "Go and read from data sheet what my driver does, I am too lazy to try to explain what I am doing" - type of thing you know... But as people asked me for more information about HW: Datasheet: https://www.rohm.com/datasheet/BD71837MWV/bd71837mwv-e (Would it be good idea to add this link to comments in MFD driver or to binding document(s)?) Page 8 contains roughly the same picture I drew below. Page 69 shows the interrupt registers. And for interested ones, HW state transitions are described on page 24. +--------------------------------------------------+ | | VSYS +-----------------+ +-----------+ | | | | | | | +-------+ | | BUCKS 1-4 +--------> | | | | | | | I2C IF +-------> H | +--------------------+ DVS +--------> | | O | | | Support | | PWRON_B +-------> S | | | +--------> | | T | | | | | PMIC_STBY_REQ +-------> | | | +--------> | | I | | | | | PMIC_ON_REQ +-------> / | | +-----------+ | | | F | | | WDOG_B +-------> | | +-----------+ | | | | | | +--------> | | | +--------------------+ BUCKS 5,8 | | | | | | | +--------> | | | | +-----------+ | | | | | | | | | | +----------+ | IRQ_OUT <-------+ | | | | | | | | +---------------------+ LDO1 +--------> C32K_OUT <-------+ | | | | | | | | | +----------+ | | | | | | | | | | +----------+ | | | | | | | | | | | +---------------------+ LDO2 +--------> | | | | | | | | | | | +----------+ | | | | | | | | | | +----------+ | | | | | | | | | | | +---------------------+ LDO7 +--------> | +-------+ | | | | | | +----------+ | | | | | | +----------+ +--------------------------> | | | | | | | +-+ BUCK6 +-+ +----------+ | | | | | | | | | | | +----------+ +------> LDO5 +--------> | | | | | | | | | +----------+ | | | | | | +-------+ | | +----------+ | | | | | o | | | XIN +---------+ 32K | | \-----> LDO3 +--------> | |Crystal| +--------------o | | | | |Driver | | +---------+ +----------+ | XOUT +---------+ | | | | | | | | +--+ BUCK7 +-+--------------------------> | +-------+ | | | | | | | +---------+ | +-----------+ | | | | | | | | | +------> LDO6 +-------> | | | | | | | | | +-----------+ | | | | | | | | +-----------+ | | | o | | | | | \-----> LDO4 +-------> | +--------------o | | | | +-----------+ | | | +--------------------------------------------------+ On the left we see input lines to PMIC. PWRON_B intended to be connected to power button. PMIC_STBY_REQ and PMIC_ON_REQ lines for controlling HW state machine PMIC has. And WDOG_B from watch dog. PMIC has control register for controlling what happens to BUCK/LDO outputs when input line states change. PMIC reports change in input lines via the IRQ_OUT line and IRQ status register. So HW mapping for interrup(s) from PMIC would be: (HW) event => BD71837 domain IRQ PMIC_STBY_REQ line level change => 0 PMIC_ON_REQ line level change => 1 PMIC_WDOG_B line level change => 2 PMIC_PWRON_B line level change => 3 PMIC_PWRON_B line/long push detected => 4 PMIC_PWRON_B line/short push detected => 5 SWRESET register on PMIC written => 6 > > "The BD71837 driver only provides the infrastructure for the IRQs. The > > users can write his own driver to convert the IRQ into the event they > > wish. The IRQ can be used with the standard > > request_irq/enable_irq/disable_irq API inside the kernel." (I found this > > text from NXP forums and ruthlessly copied and modified it over here) > > That's all OS details that have nothing to do with the binding. The > binding describes the h/w. Right. I'll drop it. > > > If this is not feasible, then I will remove the irq handling from MFD > > (or leave code there but remove the binding information?) as I don't > > know what the irq handles should do in generic case. > > I don't understand what you mean by generic. An IRQ has to be wired to > something. The only generic IRQs are GPIOs. By generic case I mean for example when PMIC_WDOG_B line changes. In example use-case I have seen, this would be cutting the power from processor. But this is not necessarily the case. This can be configured from PMIC register so that action can be warm or cold reset, or no action. Finally, I'd rather not expect that the BUCKs are supplying power to processor which is controlling the PMIC. Thus I do not know how to do generic _handler_ for these interrupts. So from PMIC HW point of view I know that the interrupt is tied to PMIC_WDOG_B line change. And this can be described in binding document. (I tried doing this to v5 patch). Still from system/SW point of view I don't know what action should be taken (or by which driver) when such change happens. Hence I liked the idea of hiding the irq register details in MFD driver by declaring it as interrupt controller - and leaving the interrupts to be used by what ever drivers need the change information is system the PMIC is used. > >> > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. > >> > + The first cell is the IRQ number. > >> > + masks from ../interrupt-controller/interrupts.txt. > > > > Sorry this "masks from ../interrupt-controller/interrupts.txt." was > > accidentally pasted here. I should have deleted it. > > > >> I'm still not clear. Generally in a PMIC, you'd define an interrupt > >> controller when there's a common set of registers to manage sub-block > >> interrupts (typical mask/unmask, ack regs) and the subblocks > >> themselves have control of masking/unmasking interrupts. If there's > >> not a need to have these 2 levels of interrupt handling, then you > >> don't really need to define an interrupt controller. > > > > And to clarify - the PMIC can generate irq via one irq line. This is > > typical ACTIVE_LOW irq with 8 bit "write 1 to clear" status register and > > 8 bit mask register. The role of interrupt-controller code here is just > > to allow these 8 irq reasons to be seen as individual BD71837 domain > > interrupts. I just don't have the driver(s) for handling these > > interrupts. > > If what I'm asking for above is still not clear, what are the 8 bits > defined as or what are those 8 lines connected to? I am sorry - there were only 7 bits. One bit was unused. I hope my explanation abowe did clarify this. > > Or should I just > > somehow state that irq X in BD71837 is a "power button short push" > > event and power button driver should be the consumer for it? > > Yes, at least, but who is the consumer is an OS detail that is not > relevant to the binding. Ideally, you would describe the node with the > interrupts property for "irq X". I think I need to try changing my mind set. I tend to think the DT nodes are for drivers so that drivers can get the information they need. An as I don't know what kind of driver would be handling the irq, I don't know what kind of DT node would be good for it. Hence I would rather leave constructing the node who consumes the IRQ to someone who knows what they want to do with this IRQ information. > > > Rest of the interrupts are not so obvious. I have no idea how I should > > handle rest of the interrupts. Those are interrupts which cause the PMIC > > to reset and cut the powers from most of the regulators too. I can > > easily think setup where one processor is controlling PMIC which powers > > for the other processor. And getting IRQ if for example watchdog reset > > the other processor would probably be very usefull. But doing any > > 'de-facto' handler for this is hard. Only generally usefull thing would > > be notifying the user-space but I don't think I should invent any new > > kernelspace - userspace interfaces for this. I believe that when such > > are needed those should be implemented by ones knowing the platform. > > Don't think about the OS or driver details. Think about sub-blocks of > the hardware and the connections between them (like irqs) and to board > that need to be described in DT. > > If you can't describe that, then you just probably shouldn't have > sub-nodes in DT (ever). This is why I did not add any "irq consumer" nodes in example DT. But I believe someone can think of a board/setup where such are needed. Thus I liked the idea of providing the interrupt-controller. > > > > So please bear with me but do you mean I should > > a) document what conditions generate which IRQ > > or > > b) should I tell what kind of driver is needed for handling the IRQs > > or > > c) should I first write code using IRQs before addinf MFD binding? > > A. So what do you think of this: +Optional properties: + - interrupt-controller : Marks the device node as an interrupt controller. + BD71837MWV can report input line state change and SW + reset events via interrupts. Different events can be seen + as separate BD71837 domain interrupts. + - #interrupt-cells : The number of cells to describe an IRQ should be 1. + The value in cell is the IRQ number. + Meaningfull numbers are: + 0 => PMIC_STBY_REQ level change + 1 => PMIC_ON_REQ level change + 2 => WDOG_B level change + 3 => Power Button level change + 4 => Power Button Long Push + 5 => Power Button Short Push + 6 => SWRESET register is written 1 Would this be getting closer to what is needed from binding document? Oh, and thanks for the patience =) Br, Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 6, 2018 at 2:34 AM, Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On Tue, Jun 05, 2018 at 10:46:14AM -0500, Rob Herring wrote: >> On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen >> <mazziesaccount@gmail.com> wrote: >> > On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote: >> >> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen >> >> <mazziesaccount@gmail.com> wrote: >> >> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: >> >> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen >> >> >> <mazziesaccount@gmail.com> wrote: >> >> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: >> >> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: >> >> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: >> >> >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD. >> >> >> >> > > + - interrupts : The interrupt line the device is connected to. >> >> >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller. >> >> >> >> > >> >> >> >> > What sub blocks have interrupts? >> >> >> >> >> >> >> >> The PMIC can generate interrupts from events which cause it to reset. >> >> >> >> Eg, irq from watchdog line change, power button pushes, reset request >> >> >> >> via register interface etc. I don't know any generic handling for these >> >> >> >> interrupts. In "normal" use-case this PMIC is powering the processor >> >> >> >> where driver is running and I do not see reasonable handling because >> >> >> >> power-reset is going to follow the irq. >> >> >> >> >> >> >> > >> >> >> > Oh, but when reading this I understand that the interrupt-controller >> >> >> > property should at least be optional. >> >> >> >> >> >> I don't think it should. The h/w either has an interrupt controller or >> >> >> it doesn't. >> >> > >> >> > I hope this explains why I did this interrupt controller - please tell >> >> > me if this is legitimate use-case and what you think of following: >> >> > >> >> > +Optional properties: >> >> > + - interrupt-controller : Marks the device node as an interrupt controller. >> >> > + BD71837MWV can report different power state change >> >> > + events to other devices. Different events can be seen >> >> > + as separate BD71837 domain interrupts. >> >> >> >> To what other devices? >> > >> > Would it be better if I wrote "other drivers" instead? I think I've seen >> > examples where MFD driver is just providing the interrupts for other >> > drivers - like power-button input driver. Currently I have no such "irq >> > consumer" drivers written. Still I would like to expose these interrupts >> > so that they are ready for using if any platform using PMIC needs them. >> >> No, worse. Interrupt binding describes interrupt connections between a >> controller and devices (which could be sub-blocks in a device), not to >> drivers. > > Ok. > >> I'm just curious as to what sub-blocks/devices there are. You don't >> have to have a driver (yet) to define the devices. > > Right. I should have done this from the start. I just thought everyone > is busy with other things and pushing people to read data sheets might > be considered as lazines. "Go and read from data sheet what my driver > does, I am too lazy to try to explain what I am doing" - type of thing > you know... But as people asked me for more information about HW: > > Datasheet: > https://www.rohm.com/datasheet/BD71837MWV/bd71837mwv-e > (Would it be good idea to add this link to comments in MFD driver or to > binding document(s)?) Yes, it would. > Page 8 contains roughly the same picture I drew > below. Page 69 shows the interrupt registers. And for interested ones, > HW state transitions are described on page 24. > > +--------------------------------------------------+ > | | > VSYS +-----------------+ +-----------+ | > | | | | | > | +-------+ | | BUCKS 1-4 +--------> > | | | | | | | > I2C IF +-------> H | +--------------------+ DVS +--------> > | | O | | | Support | | > PWRON_B +-------> S | | | +--------> > | | T | | | | | > PMIC_STBY_REQ +-------> | | | +--------> > | | I | | | | | > PMIC_ON_REQ +-------> / | | +-----------+ | > | | F | | | > WDOG_B +-------> | | +-----------+ | > | | | | | +--------> > | | | +--------------------+ BUCKS 5,8 | | > | | | | | +--------> > | | | | +-----------+ | > | | | | | > | | | | +----------+ | > IRQ_OUT <-------+ | | | | | > | | | +---------------------+ LDO1 +--------> > C32K_OUT <-------+ | | | | | > | | | | +----------+ | > | | | | | > | | | | +----------+ | > | | | | | | | > | | | +---------------------+ LDO2 +--------> > | | | | | | | > | | | | +----------+ | > | | | | | > | | | | +----------+ | > | | | | | | | > | | | +---------------------+ LDO7 +--------> > | +-------+ | | | | > | | +----------+ | > | | | > | | +----------+ +--------------------------> > | | | | | | > | +-+ BUCK6 +-+ +----------+ | > | | | | | | | | > | | +----------+ +------> LDO5 +--------> > | | | | | | > | | | +----------+ | > | | | | > | +-------+ | | +----------+ | > | | | | o | | | > XIN +---------+ 32K | | \-----> LDO3 +--------> > | |Crystal| +--------------o | | | > | |Driver | | +---------+ +----------+ | > XOUT +---------+ | | | | | > | | | +--+ BUCK7 +-+--------------------------> > | +-------+ | | | | | > | | +---------+ | +-----------+ | > | | | | | | > | | +------> LDO6 +-------> > | | | | | | > | | | +-----------+ | > | | | | > | | | +-----------+ | > | | o | | | > | | \-----> LDO4 +-------> > | +--------------o | | | > | +-----------+ | > | | > +--------------------------------------------------+ > > On the left we see input lines to PMIC. PWRON_B intended to be connected > to power button. PMIC_STBY_REQ and PMIC_ON_REQ lines for controlling HW > state machine PMIC has. And WDOG_B from watch dog. > > PMIC has control register for controlling what happens to BUCK/LDO > outputs when input line states change. PMIC reports change in input > lines via the IRQ_OUT line and IRQ status register. So it looks like this is just regulators with a few other signals to handle. > So HW mapping for interrup(s) from PMIC would be: > > (HW) event => BD71837 domain IRQ > > PMIC_STBY_REQ line level change => 0 > PMIC_ON_REQ line level change => 1 I'm not really clear how these would have s/w handling. They look like handshake signals for the processor to enter and exit standby/suspend. H/w designers don't always know what to do with things and may have just said lets have an interrupt for every input signal. I'd think you would just want DT properties to configure what action to take (and perhaps polarity?). > PMIC_WDOG_B line level change => 2 Ah, this is an input signal, not a watchdog block within the PMIC. I think this should just be handled by the core driver. If you need to configure what this does, then we can add a property to handle that. > PMIC_PWRON_B line level change => 3 > PMIC_PWRON_B line/long push detected => 4 > PMIC_PWRON_B line/short push detected => 5 So you need a power button driver (or maybe not even a separate driver) for this, but I don't think that warrants a child node. I think some PMIC drivers just generate a power key press (which just gets punted to userspace), but some will do an actual power down. Or maybe a combination of those based on short/long press. I think there's already some DT properties defined to control the behavior as well. > SWRESET register on PMIC written => 6 Probably this can be handled within the core driver. Seems like you'd only use this if you have separate entities that write and read this. If you don't know, then just ignore it for now. >> > "The BD71837 driver only provides the infrastructure for the IRQs. The >> > users can write his own driver to convert the IRQ into the event they >> > wish. The IRQ can be used with the standard >> > request_irq/enable_irq/disable_irq API inside the kernel." (I found this >> > text from NXP forums and ruthlessly copied and modified it over here) >> >> That's all OS details that have nothing to do with the binding. The >> binding describes the h/w. > > Right. I'll drop it. > >> >> > If this is not feasible, then I will remove the irq handling from MFD >> > (or leave code there but remove the binding information?) as I don't >> > know what the irq handles should do in generic case. >> >> I don't understand what you mean by generic. An IRQ has to be wired to >> something. The only generic IRQs are GPIOs. > > By generic case I mean for example when PMIC_WDOG_B line changes. In > example use-case I have seen, this would be cutting the power from > processor. But this is not necessarily the case. This can be configured > from PMIC register so that action can be warm or cold reset, or no > action. Finally, I'd rather not expect that the BUCKs are supplying > power to processor which is controlling the PMIC. Thus I do not know how > to do generic _handler_ for these interrupts. > > So from PMIC HW point of view I know that the interrupt is tied to > PMIC_WDOG_B line change. And this can be described in binding document. > (I tried doing this to v5 patch). Still from system/SW point of view I > don't know what action should be taken (or by which driver) when such > change happens. Hence I liked the idea of hiding the irq register > details in MFD driver by declaring it as interrupt controller - and > leaving the interrupts to be used by what ever drivers need the change > information is system the PMIC is used. This can still be done but doesn't have to be in DT. >> >> > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. >> >> > + The first cell is the IRQ number. >> >> > + masks from ../interrupt-controller/interrupts.txt. >> > >> > Sorry this "masks from ../interrupt-controller/interrupts.txt." was >> > accidentally pasted here. I should have deleted it. >> > >> >> I'm still not clear. Generally in a PMIC, you'd define an interrupt >> >> controller when there's a common set of registers to manage sub-block >> >> interrupts (typical mask/unmask, ack regs) and the subblocks >> >> themselves have control of masking/unmasking interrupts. If there's >> >> not a need to have these 2 levels of interrupt handling, then you >> >> don't really need to define an interrupt controller. >> > >> > And to clarify - the PMIC can generate irq via one irq line. This is >> > typical ACTIVE_LOW irq with 8 bit "write 1 to clear" status register and >> > 8 bit mask register. The role of interrupt-controller code here is just >> > to allow these 8 irq reasons to be seen as individual BD71837 domain >> > interrupts. I just don't have the driver(s) for handling these >> > interrupts. >> >> If what I'm asking for above is still not clear, what are the 8 bits >> defined as or what are those 8 lines connected to? > > I am sorry - there were only 7 bits. One bit was unused. I hope my > explanation abowe did clarify this. > >> > Or should I just >> > somehow state that irq X in BD71837 is a "power button short push" >> > event and power button driver should be the consumer for it? >> >> Yes, at least, but who is the consumer is an OS detail that is not >> relevant to the binding. Ideally, you would describe the node with the >> interrupts property for "irq X". > > I think I need to try changing my mind set. I tend to think the DT nodes > are for drivers so that drivers can get the information they need. An as > I don't know what kind of driver would be handling the irq, I don't know > what kind of DT node would be good for it. Hence I would rather leave > constructing the node who consumes the IRQ to someone who knows what > they want to do with this IRQ information. > >> >> > Rest of the interrupts are not so obvious. I have no idea how I should >> > handle rest of the interrupts. Those are interrupts which cause the PMIC >> > to reset and cut the powers from most of the regulators too. I can >> > easily think setup where one processor is controlling PMIC which powers >> > for the other processor. And getting IRQ if for example watchdog reset >> > the other processor would probably be very usefull. But doing any >> > 'de-facto' handler for this is hard. Only generally usefull thing would >> > be notifying the user-space but I don't think I should invent any new >> > kernelspace - userspace interfaces for this. I believe that when such >> > are needed those should be implemented by ones knowing the platform. >> >> Don't think about the OS or driver details. Think about sub-blocks of >> the hardware and the connections between them (like irqs) and to board >> that need to be described in DT. >> >> If you can't describe that, then you just probably shouldn't have >> sub-nodes in DT (ever). > > This is why I did not add any "irq consumer" nodes in example DT. But I > believe someone can think of a board/setup where such are needed. Thus I > liked the idea of providing the interrupt-controller. > >> > >> > So please bear with me but do you mean I should >> > a) document what conditions generate which IRQ >> > or >> > b) should I tell what kind of driver is needed for handling the IRQs >> > or >> > c) should I first write code using IRQs before addinf MFD binding? >> >> A. > > > So what do you think of this: > > +Optional properties: > + - interrupt-controller : Marks the device node as an interrupt controller. > + BD71837MWV can report input line state change and SW > + reset events via interrupts. Different events can be seen > + as separate BD71837 domain interrupts. > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. > + The value in cell is the IRQ number. > + Meaningfull numbers are: > + 0 => PMIC_STBY_REQ level change > + 1 => PMIC_ON_REQ level change > + 2 => WDOG_B level change > + 3 => Power Button level change > + 4 => Power Button Long Push > + 5 => Power Button Short Push > + 6 => SWRESET register is written 1 > > Would this be getting closer to what is needed from binding document? I don't think any of this needs to live in DT. All you really need a separate driver (and hence irq) for is really just the power button. You can just define the interrupts within the kernel. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 06, 2018 at 10:16:37AM -0500, Rob Herring wrote: > On Wed, Jun 6, 2018 at 2:34 AM, Matti Vaittinen > <mazziesaccount@gmail.com> wrote: > > On Tue, Jun 05, 2018 at 10:46:14AM -0500, Rob Herring wrote: > >> On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen > >> <mazziesaccount@gmail.com> wrote: > >> > On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote: > >> >> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen > >> >> <mazziesaccount@gmail.com> wrote: > >> >> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: > >> >> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > >> >> >> <mazziesaccount@gmail.com> wrote: > >> >> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > >> >> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > >> >> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > > Datasheet: > > https://www.rohm.com/datasheet/BD71837MWV/bd71837mwv-e > > (Would it be good idea to add this link to comments in MFD driver or to > > binding document(s)?) > > Yes, it would. I will add this then. I don't really like adding links like this as urls tend to change and links become dead - but I guess this is something we just must live with. > > +--------------------------------------------------+ > > | | > > VSYS +-----------------+ +-----------+ | > > | | | | | > > | +-------+ | | BUCKS 1-4 +--------> > > | | | | | | | > > I2C IF +-------> H | +--------------------+ DVS +--------> > > | | O | | | Support | | > > PWRON_B +-------> S | | | +--------> > > | | T | | | | | > > PMIC_STBY_REQ +-------> | | | +--------> Do you think this ASCII art picture in MFD or regulator driver comments would be an overkill? > > On the left we see input lines to PMIC. PWRON_B intended to be connected > > to power button. PMIC_STBY_REQ and PMIC_ON_REQ lines for controlling HW > > state machine PMIC has. And WDOG_B from watch dog. > > > > PMIC has control register for controlling what happens to BUCK/LDO > > outputs when input line states change. PMIC reports change in input > > lines via the IRQ_OUT line and IRQ status register. > > So it looks like this is just regulators with a few other signals to handle. Yes. Regulators and the HW state machine which is currently mostly bypassed by drivers. And while we are at it - is there some standard device-tree properties for describing the voltages for different PMIC states (idle, run, standby) so that the driver could configure voltages the bucks should use when PMIC state is changed. Or do you think I should use custom ones like: bd71837,pmic-buck1-dvs-voltage = <900000>, <850000>, <800000>; /* VDD_SOC: Run-Idle-Suspend */ bd71837,pmic-buck2-dvs-voltage = <1000000>, <900000>, <0>; /* VDD_ARM: Run-Idle */ bd71837,pmic-buck3-dvs-voltage = <1000000>, <0>, <0>; /* VDD_GPU: Run */ bd71837,pmic-buck4-dvs-voltage = <1000000>, <0>, <0>; /* VDD_VPU: Run */ I think this is not the only PMIC with configurable voltages for different states so someone has probably already invented a way to provide this information - is the DT correct place to search for this? > > > So HW mapping for interrup(s) from PMIC would be: > > > > (HW) event => BD71837 domain IRQ > > > > PMIC_STBY_REQ line level change => 0 > > PMIC_ON_REQ line level change => 1 > > I'm not really clear how these would have s/w handling. They look like > handshake signals for the processor to enter and exit standby/suspend. > H/w designers don't always know what to do with things and may have > just said lets have an interrupt for every input signal. The PMIC_ON_REQ can be used to switch the PMIC from 'READY' to 'SNVS' and from 'SNVS' to 'RUN' states. But same transitions can be configured to be done by power button presses too. I think I in some earlier mail said that I can't think how to handle other but power button interrupts - when PMIC is used to power the processor controlling PMIC. But I also mentioned another use case which I can think of - but I am not sure if it is relevant or not. In this other use case we have a 'slave processor' powered by PMIC doing some specific tasks - and a 'control processor' which is not powered by this PMIC - but which may be controlling it (and thus also controls power for the slave). In such setup all these interrupts mmight become meaningfull - but handling should be platform specific then. (The control processor could for example detect slave processor resets or wake-ups via these interrupts and initiate any platform specific activities based on this). I have no system design experience so I don't know if this sounds reasonable or not - but thats why I liked the idea of providing access to all interrupts via this interrupt-controller. > I'd think you > would just want DT properties to configure what action to take (and > perhaps polarity?). Currently the driver is not configuring what happens when state of these signals change. But it could as you say. And it would be nice to get the configuration from DT. I think the polarity is fixed. > > PMIC_WDOG_B line level change => 2 > > Ah, this is an input signal, not a watchdog block within the PMIC. I > think this should just be handled by the core driver. If you need to > configure what this does, then we can add a property to handle that. Action taken when WDOG_B is asserted is indeed configurable. PMIC can do cold reset, warm reset of take no action. But here I again fail to think how this should be handled - especially because HW default for action is cold reset. But as I said abowe - it may be there is use case for this interrupt even though I can't provide generic one. ...and this is why I liked the idea of having it available via DT... :) > > > PMIC_PWRON_B line level change => 3 > > PMIC_PWRON_B line/long push detected => 4 > > PMIC_PWRON_B line/short push detected => 5 > > So you need a power button driver (or maybe not even a separate > driver) for this, but I don't think that warrants a child node. I > think some PMIC drivers just generate a power key press (which just > gets punted to userspace), but some will do an actual power down. Or > maybe a combination of those based on short/long press. I agree with you on this. A power button driver could consume these IRQs. And yes, (input?) event to user-space sounds reasonable. Maybe also a power-off handler if "system-power-controller" property is given. Whether this is something crying for own DT node is not my decision. I just know that having own sub nodes and relying on irq-controller xlate callbacks eould make driver side really simple. > > I think there's already some DT properties defined to control the > behavior as well. > > > SWRESET register on PMIC written => 6 > > Probably this can be handled within the core driver. Seems like you'd > only use this if you have separate entities that write and read this. > If you don't know, then just ignore it for now. Yep. My plan was not to implement handling for any of these interrupts for now. I just wanted to make them easily available for any future use. > > Hence I liked the idea of hiding the irq register > > details in MFD driver by declaring it as interrupt controller - and > > leaving the interrupts to be used by what ever drivers need the change > > information is system the PMIC is used. > > This can still be done but doesn't have to be in DT. I think this is my weak spot. I don't know how to do this easily without DT. How do I bring the irq to power-button driver or to WDOG irq handler (or XXX-driver invented by one who needs these IRQs) without DT. Options I can think of are: 1. getting the GPIO irq (from MFD parent) and making the IRQ registers visible to power button/XXX drivers. Possibly ending up with shared IRQ hanlder. 2. Keeping the IRQ register accesses in MFD driver and providing some handler callback registration interface from MFD driver to power button/XXX drivers 3. Using this interrupt-controller approach. I dislike option 1 because all drivers using IRQs need to be aware of IRQ registers. I dislike option 2 because inventing such IRQ callbacks just feel wrong. There must be better way - I just don't know it =) I would like to use option 3 - but I don't know how to do it without DT? Specifically I don't know how to provide the irq number and interrupt parent to power-button/XXX drivers if they are not brought from DT. And why to invent some parallel mechanism for this when DT usage already provides this. I would be really gratefull for any tips how to do this correctly if DT is not used. > > So what do you think of this: > > > > +Optional properties: > > + - interrupt-controller : Marks the device node as an interrupt controller. > > + BD71837MWV can report input line state change and SW > > + reset events via interrupts. Different events can be seen > > + as separate BD71837 domain interrupts. > > + - #interrupt-cells : The number of cells to describe an IRQ should be 1. > > + The value in cell is the IRQ number. > > + Meaningfull numbers are: > > + 0 => PMIC_STBY_REQ level change > > + 1 => PMIC_ON_REQ level change > > + 2 => WDOG_B level change > > + 3 => Power Button level change > > + 4 => Power Button Long Push > > + 5 => Power Button Short Push > > + 6 => SWRESET register is written 1 > > > > Would this be getting closer to what is needed from binding document? > > I don't think any of this needs to live in DT. All you really need a > separate driver (and hence irq) for is really just the power button. > You can just define the interrupts within the kernel. So I tried to argue that all of the IRQs should be usable and we should not limit the HW capabilities by design (I like the idea of exposing all HW functionality because I only rarely know what should be usable better than the user). Are you sure my dual processor use-case is not convincing you we should provide these interrupts via DT? If so - as I already said, I would be gratefull for any suggestions on how to provide access to irqs without DT. I just can't help feeling that DT would have been the best way for cleanest and most understandable/usable end result. Meanwhile I will prepare a patch where the interrupt handling is completely ripped from MFD and binding documents as I don't have power button driver tested (I drafted something though). Maybe such a patch could be acceptable in order to enable regulator usage (and compilation). Is that Ok? Best Regards Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 07, 2018 at 02:12:18PM +0300, Matti Vaittinen wrote: > On Wed, Jun 06, 2018 at 10:16:37AM -0500, Rob Herring wrote: > > On Wed, Jun 6, 2018 at 2:34 AM, Matti Vaittinen > > <mazziesaccount@gmail.com> wrote: > > > On Tue, Jun 05, 2018 at 10:46:14AM -0500, Rob Herring wrote: > > >> On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen > > >> <mazziesaccount@gmail.com> wrote: > > >> > On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote: > > >> >> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen > > >> >> <mazziesaccount@gmail.com> wrote: > > >> >> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote: > > >> >> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen > > >> >> >> <mazziesaccount@gmail.com> wrote: > > >> >> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote: > > >> >> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote: > > >> >> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote: > > So it looks like this is just regulators with a few other signals to handle. > > Yes. Regulators and the HW state machine which is currently mostly > bypassed by drivers. And while we are at it - is there some standard > device-tree properties for describing the voltages for different PMIC states > (idle, run, standby) so that the driver could configure voltages the > bucks should use when PMIC state is changed. Or do you think I should > use custom ones like: > > bd71837,pmic-buck1-dvs-voltage = <900000>, <850000>, <800000>; /* VDD_SOC: Run-Idle-Suspend */ > bd71837,pmic-buck2-dvs-voltage = <1000000>, <900000>, <0>; /* VDD_ARM: Run-Idle */ > bd71837,pmic-buck3-dvs-voltage = <1000000>, <0>, <0>; /* VDD_GPU: Run */ > bd71837,pmic-buck4-dvs-voltage = <1000000>, <0>, <0>; /* VDD_VPU: Run */ > > I think this is not the only PMIC with configurable voltages for > different states so someone has probably already invented a way to > provide this information - is the DT correct place to search for this? I will leave this out for now. Guess this can be added later. > > > > > > So HW mapping for interrup(s) from PMIC would be: > > > > > > (HW) event => BD71837 domain IRQ > > > > > > PMIC_STBY_REQ line level change => 0 > > > PMIC_ON_REQ line level change => 1 > > > > I'm not really clear how these would have s/w handling. They look like > > handshake signals for the processor to enter and exit standby/suspend. > > H/w designers don't always know what to do with things and may have > > just said lets have an interrupt for every input signal. > Well, I will only handle the power button irq as you suggested for now. > > > PMIC_PWRON_B line level change => 3 > > > PMIC_PWRON_B line/long push detected => 4 > > > PMIC_PWRON_B line/short push detected => 5 > > > > So you need a power button driver (or maybe not even a separate > > driver) for this, but I don't think that warrants a child node. I > > think some PMIC drivers just generate a power key press (which just > > gets punted to userspace), but some will do an actual power down. Or > > maybe a combination of those based on short/long press. I add power button driver (and input subsystem people) tp next patch set. I think I will later also add power/reset driver because PMIC can do reset for the system. Unfortunately the PMIC can't provide power-off. But I leave this out from this series. > > I think there's already some DT properties defined to control the > > behavior as well. > > > > > SWRESET register on PMIC written => 6 > > > > Probably this can be handled within the core driver. Seems like you'd > > only use this if you have separate entities that write and read this. > > If you don't know, then just ignore it for now. I planned to use SWRESET for power/reset driver - but irq handling is not needed there. > > > Hence I liked the idea of hiding the irq register > > > details in MFD driver by declaring it as interrupt controller - and > > > leaving the interrupts to be used by what ever drivers need the change > > > information is system the PMIC is used. > > > > This can still be done but doesn't have to be in DT. > > I think this is my weak spot. I don't know how to do this easily without > DT. I think I found the correct way - I'll send the patch v6 soon. I hope it addresses this issue correctly. Best Regards Matti Vaittinen -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt new file mode 100644 index 000000000000..bbc46d38b162 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt @@ -0,0 +1,52 @@ +* ROHM BD71837 Power Management Integrated Circuit bindings + +BD71837MWV is a programmable Power Management IC for powering single-core, +dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for +low BOM cost and compact solution footprint. It integrates 8 Buck +egulators and 7 LDO’s to provide all the power rails required by the SoC and +the commonly used peripherals. + +Required properties: + - compatible : Should be "rohm,bd71837". + - reg : I2C slave address. + - interrupt-parent : Phandle to the parent interrupt controller. + - interrupts : The interrupt line the device is connected to. + - interrupt-controller : Marks the device node as an interrupt controller. + - #interrupt-cells : The number of cells to describe an IRQ, should be 1 or 2. + The first cell is the IRQ number. + The second cell if present is the flags, encoded as trigger + masks from ../interrupt-controller/interrupts.txt. + - regulators: : List of child nodes that specify the regulators + Please see ../regulator/rohm,bd71837-regulator.txt + - clock: : Please see ../clock/rohm,bd71837-clock.txt + +Example: + + pmic: bd71837@4b { + compatible = "rohm,bd71837"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x4b>; + interrupt-parent = <&gpio1>; + interrupts = <29 GPIO_ACTIVE_LOW>; + interrupt-names = "irq"; + #interrupt-cells = <1>; + interrupt-controller; + + regulators { + buck1: BUCK1 { + regulator-name = "buck1"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1300000>; + regulator-boot-on; + regulator-ramp-delay = <1250>; + }; + ... + }; + clk: bd71837-32k-out { + compatible = "rohm,bd71837-clk"; + #clock-cells = <0>; + clock-frequency = <32768>; + clock-output-names = "bd71837-32k-out"; + }; + };
Document devicetree bindings for ROHM BD71837 PMIC MFD. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> --- .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt