Re: [RFC PATCH 2/2] mfd: rohm-bd71828: Add power off functionality

[Matti Vaittinen]

Hi Andreas,

On 3/25/24 14:16, Andreas Kemnade wrote:
> On Mon, 25 Mar 2024 13:31:15 +0200
> Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
>
> > On 3/24/24 22:12, Andreas Kemnade wrote:
> > > Since the chip can power off the system, add the corresponding
> > > functionality.
> > > Based on https://github.com/kobolabs/Kobo-Reader/raw/master/hw/imx6sll-clara2e/kernel.tar.bz2
> > > No information source about the magic numbers found.
> >
> > Oh, interesting repository :) Thanks for linking to it! I didn't know
> > someone had reworked this driver...
> which btw: contains this interesting snippet (output from fdtdump)
>    bd71828-i2c@4b {
>                      reg = <0x0000004b>;
>                      compatible = "rohm,bd71828";
>                      gpio_int = <0x00000008 0x00000013 0x00000001>;
>                      gpio_wdogb = <0x00000039 0x00000018 0x00000001>;
>                      #address-cells = <0x00000001>;
>                      #size-cells = <0x00000000>;
>                      pmic@4b {
>                          compatible = "rohm,bd71828";
>               	        regulators {
>                          	BUCK1 {
>                              		regulator-name = "buck1";
>
>
> and to make it work since basically no regulators are registered
> instead just some regmap_write()s are done to configure something
> in probe(). It is a pitfall to think that the information below pmic@4b
> is used, especially since it is not that obvious in the source.

Just to ensure there will be no misunderstanding - I have not authored 
the modifications seen in "Kobo-Reader" repository. Upstream driver does 
register the regulators - and it does not use the oddly named gpio_int 
or the gpio_wdogb:

https://elixir.bootlin.com/linux/v6.9-rc1/source/drivers/regulator/bd71828-regulator.c#L750

> > I have access to the data-sheets so I also have some pieces of
> > information. I hope I can clarify part of the puzzle. Unfortunately I
> > have no information about the magic delays. I guess I could try asking
> > though.
> >
> > Oh, it seems to me this handler is only working on BD71828, not on
> > BD71815. So, it should be tied to the ROHM_CHIP_TYPE_BD71828.
> >
> > > Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
> > > ---
> > >    drivers/mfd/rohm-bd71828.c | 31 ++++++++++++++++++++++++++++++-
> > >    1 file changed, 30 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> > > index 594718f7e8e1..5a55aa3620d0 100644
> > > --- a/drivers/mfd/rohm-bd71828.c
> > > +++ b/drivers/mfd/rohm-bd71828.c
> > > @@ -464,6 +464,24 @@ static int set_clk_mode(struct device *dev, struct regmap *regmap,
> > >    				  OUT32K_MODE_CMOS);
> > >    }
> > >    
> > > +static struct i2c_client *bd71828_dev;
> >
> > I'm not sure why to store pointer to the device and not a pointer to the
> > regmap?
> >
> > > +static void bd71828_power_off(void)
> > > +{
> > > +	i2c_smbus_write_byte_data(bd71828_dev, 0x03, 0xff);
> >
> > 0x03 is a "reset reason" - register. Spec I have states that the
> > register should clear when a reset occurs - but it also says the bits
> > are "write '1' to clear". So, for some reason(?), this clears the
> > previous reset reason.
>
> well, so just check in bootloader what the reset reason is and check if
> there is anything odd.

I understand why bootloader would check this register - but I don't 
understand why the driver would clear it as it should be cleared by 
reset (unless I missread the spec).

> > I am unsure why i2c_smbus_write_byte_data() and
> > not regmap()?
> regmap involves mutex_lock() and we are not allowed to sleep here.

Right. It makes perfect sense now. Thanks! (Do you think it's worth a 
comment?)

> > > +	mdelay(500);
> > > +	i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_INT_DCIN2, 0x02);
> >
> > This clears the DCIN monitoring status bit from the IRQ status register.
> > I don't understand the purpose though.
> so maybe something to prevent power on by just plugging a usb cable? Will
> experiment a bit with it.

I still think this is odd because, if I read it right, this is an IRQ 
status and not a mask register. Well, wouldn't be a first undocumented 
"feature" I see...

> > > +	mdelay(500);
> > > +	while (true) {
> > > +		i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_PS_CTRL_1, 0x02);
> >
> > This write to PS_CTRL_1 initiates a state transition. 0x2 equals to HBNT
> > state. Eg, in usual cases this should be a start of the power-off sequence.
> >
> > > +		mdelay(500);
> > > +	}
> > > +}
> >
> > If you have the hardware to test this on, then it'd be great to see if
> > clearing the reset reason and IRQ status could be dropped. I can't
> > immediately think of a reason for those.
> I will to so. That will also remove the need for all those delays.

Thanks :) Very much appreciated!

Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~