Battery driver is a special one because the framework doesn't define any ioctl to enable/disable the device, which means you have to enable it in register.
On Tue, Sep 6, 2022 at 10:18 PM TimH <t...@jti.uk.com.invalid> wrote: > Thanks! > > I think I will take the following approach: > > - Use Kconfig to determine the default setup (which regulators are > enabled, and their voltage). If another user wants to do this manually it > can be achieved by disabling them in Kconfig and using ioctl to set them > manually > - have first initialisation of the device via the device register function > - since the ACT8945A has no chip ID register to read, I can readback > another register and check it matches what it should be (based on Kconfig > and initial setup) and abort the device registration if there's a problem > (most likely caused by the device not being there or otherwise failed). > > Think that should do it. > > Thank you as ever, Alan, for taking the time to help me. > > FYI I am awaiting 11.0 release and will then rebase to that, and submit my > first PR's for my new drivers 😊 > > >-----Original Message----- > >From: Alan Carvalho de Assis <acas...@gmail.com> > >Sent: 06 September 2022 15:08 > >To: dev@nuttx.apache.org > >Subject: Re: Driver for combined battery charger and regulator > > > >Hi Tim, > > > >I think you can implement a register and a initialization as separated > functions, > >if you search you will find some drivers implemented that way. > > > >I remember a developer that complained about the fact the some sensors are > >initialized automatically during the register phase and it was bad for > him > >because he was developing a low power device, so he needs to go through > >ioctl to fix that issue. > > > >Currently I think the approach is make it works from scratch, but of > course it > >could be an issue for some usage. > > > >This is something we need to revisit in the future. > > > >Other thing is an issue is that some drivers don't have a probe (some > kind of > >prove of existence), it just assumes the device is there in the SPI/I2C > bus and > >don't try to talk with it and goes on creating the device file. It makes > the file of > >user hard because he see the device at /dev and think that everything is > fine. > > > >BR, > > > >Alan > > > >On 9/6/22, TimH <t...@jti.uk.com.invalid> wrote: > >> Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using > >> the battery charger element on this board iteration so I can leave it > >> for later. > >> > >> Any thoughts on my mental tussles regarding registering vs. > initialising? > >> > >>>-----Original Message----- > >>>From: Alan Carvalho de Assis <acas...@gmail.com> > >>>Sent: 06 September 2022 13:51 > >>>To: dev@nuttx.apache.org > >>>Subject: Re: Driver for combined battery charger and regulator > >>> > >>>Hi Tim, > >>> > >>>AFAIK we don't have a PMIC with battery regulator in the mainline yet. > >>>So you don't have a reference to base on it. > >>> > >>>You don't need to create a single file with all functions on it, you > >>>can create separated file for each specific function. This is how > >>>MC13892 is implemented on Linux (please don't look the source code, it > >>>is GPL), this chip is a PMIC with regulator, battery charger and LEDs > >>>control. > >>> > >>>I think for ACT8945A should be included a regulator at > >>>drivers/power/supply/ and will implement the functions from > >>><nuttx/power/regulator.h> and will register itself with > >>>regulator_register(). > >>> > >>>Also you will include the battery charger logic at > >>>driver/power/battery/ as a separated act8945_batchr.c to avoid mixing > >>>things and will export itself as /dev/bat0. > >>> > >>>But you will need to use spinlock when accessing the I2C bus inside > >>>these drivers to avoid both drivers trying to use it while a transfer > >>>is in progress. > >>> > >>>BR, > >>> > >>>Alan > >>> > >>>On 9/6/22, TimH <t...@jti.uk.com.invalid> wrote: > >>>> I'm writing a driver for the Quorvo ACT8945A device. This is a > >>>> combined 7-output programmable regulator AND Li-ion battery charger, > >>>> all > >>>in one. > >>>> > >>>> > >>>> > >>>> I see there are existing "regulator.h" and "battery_charger.h" > >>>> driver templates. > >>>> > >>>> > >>>> > >>>> Would my best approach to be to create a driver using a new (e.g.) > >>>> "battery_charger_regulator.h" template combining that existing > >>>> functionality or is there another, preferred, approach? > >>>> > >>>> > >>>> > >>>> Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? > >>>> Or something else? > >>>> > >>>> > >>>> > >>>> Then, once that is decided, I seem to have a mental block when it > >>>> comes to device initialisation vs registering. > >>>> > >>>> > >>>> > >>>> In my mind, registering should just create the /dev/xxxx entry and > >>>> initialise the relevant structs, but not touch the device itself? > >>>> But some drivers do go on to actually set up the device, whereas I > >>>> think that should be a separate "init" function called independently > >>>> of the > >>>"register" > >>>> function, or a specific ioctl perhaps? What is the best practice here? > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> > >>>> > >>>> Tim. > >>>> > >>>> > >>>> > >>>> > >> > >> > >
