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