[Letux-kernel] [PATCH 0/6] bq2429x: Clean up driver for future fixes

[H. Nikolaus Schaller]

Hi,
I finally have fixed the OTG mode. What is still a little unstable is turning on charging.

And what I am not sure about is handling the F_EN_HIZ bit when switching between OTG and
Client mode. It may not be properly reset to the state before OTG mode
(i.e. input_current_limit = 0mA if that was defined through writing sysfs).

Code is now rebased on letux-5.9-rc3 which still includes the older code.

Your patch set sits on top of that and I have appended my fixes and tried to write good commit
messages so that it should be easy to follow and discuss. The patches including yours are

	letux-letux-5.9-rc3..work-bq2429x

in this branch:

	https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-bq2429x

If this works well enough (or has got additional fixes) I think we can squash everything
into 3 or 4 patches that can replace letux/bq2429x-v5 i.e. become letux/bq2429x-v6.

Then we can do fine-tuning to make it ready for upstream submission.

I think that this can and should be done as a first step to submit Pyra specific stuff.
For upstream support of the Pyra device tree the main blocking point is the MIPI DSI driver
which does not yet support DRM panels (and I do not want to submit it without any display
support). But we won't get our panel driver upstream before it has been converted.

So we have to wait until omapdrm supports generic MIPI DRM panels and we have converted
our panel driver. Then my plan is to submit the panel driver and finally an 80% complete
Pyra device tree. The remaining 20% are for further study like nub driver, sensors, mmc switch,
tiler rotation, etc. how long do we have to wait for that? Maybe v5.11 or v5.12 i.e. 6-9 months.
Depends on how quickly Sebastian Reichel is doing the Droid 4 work...

Thanks for converting the driver to regmap, which makes it much easier and safer
to compare code to the data sheet description.

BR,
Nikolaus


> Am 22.08.2020 um 00:55 schrieb Nick Elsmore <nicholaselsmore at gmail.com>:
> 
> > I also saw the high temperature issue on 5.6 when charging sometimes - I guess
> > you know already from your previous bq work but "60°" just means too hot to
> > charge as there is no exact readout. This also resulted in a "HOT" print from
> > the driver.
> 
> Yes, there are only three levels: too cold, of, too hot. And these are mapped
> to -10°C, 22.5°C and 60°C.
> 
> But the battery wasn't charging (battery is full) and after a reboot it did read
> out correctly. So it was a driver glitch. And I never had that with the old driver.
> 
> I remember that these bits reporting NTC temperature are not easy to be handled
> correctly by the driver so the rework may have changed something subtle.
> 
> 
> I have seen this on the old driver on 5.6.y.  I will see if I can reproduce again on the old driver and get a register dump and some other information.  Re-examining the logic in the restructure patches, the reporting in the NTC fields looks ok.  So there may be something in the configuration of the chip causing these NTC bits to be set.  Have you dumped the registers when you reproduce this issue to see if the actual values are as expected?
>  
> >> I have started a little to test your patches on top of v5.8-rc7 (including
> >> also David's patches so that the Panel is working again).
> >> There was a missing comma - easy to fix for compilation.
> 
> Yes I noticed that, sorry.  Something broke in my submission.
>  
> >> Basically the driver seems to work, but OTG doesn't. It does not even try to
> >> switch power on, although DWC3 detects it.
> >> 
> >> Unplugging the OTG cable once did lead to:
> >> 
> >> root at letux:~# [  397.149733] ------------[ cut here ]------------
> >> [  397.154707] WARNING: CPU: 0 PID: 37 at drivers/regulator/core.c:2603
> >> _regulator_disable+0x3c/0x168
> >> [  397.170413] unbalanced disables for otg_path
> 
> This is interesting.  I don't have a device handy to test OTG, so this is probably why I didn't catch this.  I'll try and get a device to test OTG mode with.
>  
> >> And once the temperature report was 60°C.
> >> 
> >> So I think there is something wrong with interrupts / status change detection.
> >> Just a note: I have tested on an older Pyra prototype with tca6424 and there,
> >> IRQs are definitively broken. So we must poll the status bits.
> 
> Also interesting, I'll need to investigate what broke with the interrupts.  My original driver rewrite behaved quite well on 4.19. 
>