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