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. >>>> >>>> >>>> >>>> >> >>
