Hi Tim, You are welcome!
That is a good idea, defining the initial voltage for each channel on Kconfig will make user life easier. BR, Alan On 9/6/22, 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. >>>>> >>>>> >>>>> >>>>> >>> >>> > >
