archive mirror
 help / color / mirror / Atom feed
From: Chris Lapa <>
To: "Pali Rohár" <>
Cc:, Sebastian Reichel <>,,
Subject: Re: BQ27xxx registers
Date: Thu, 22 Dec 2016 10:37:56 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <201612211346.17265@pali>

On 21/12/16 11:46 pm, Pali Rohár wrote:
> On Wednesday 21 December 2016 03:49:10 Chris Lapa wrote:
>> On 20/12/16 10:34 pm, Pali Rohár wrote:
>>> On Tuesday 20 December 2016 07:00:41 Chris Lapa wrote:
>>>> I can generate a patch to fix this issue, however the bigger
>>>> problem exists as to which revision fuel gauge the
>>>> bq27xxx_battery.c driver is intended to support for each family.
>>> Hi! I think driver should support all revisions. There can be (and
>>> probably really is) hardware which uses old revision and such
>>> hardware should be still supported...
>> I agree. However due to the register address changes across the
>> spectrum of revisions, each revision will have to be specified
>> individually. For example, we will need to implement a BQ27510G1,
>> BQ27510G2, BQ27510G3, BQ27520G1, BQ27520G2, BQ27520G3, BQ27520G4
>> definitions and prospective device tree additions ti,bq27510g1,
>> ti,bq27510g2 etc.
>> The other option is to aim for bottom of the barrel support for all
>> the devices under the BQ27500 definition but my feeling is it would
>> get messier fast and be less maintainable.
>> My preference is to go with the first option if you agree?
> Yes. If those chips have different register addresses, then those chips
> are different. Name, generation or suffix does not matter here.
> Similarly there could be chips with different name, but same addresses,
> so can use one driver/configuration without any change.
> So I'm for different name in device tree (or platform data or what is
> being used) to distinguish between different revisions.

I've been working my way through the revision migration datasheets and 
noticed this could be simplified with the FW_VERSION parameter. It is 
always located at the same address and is distinctly different between 
each chip revision. Unfortunately the migration datasheets vs individual 
revision datasheets firmware version information directly contradict 
each other. Which makes me wary of committing to using it.

Given that I don't have every single variant of this device to test 
with, its probably still safest to have the user manually specify each 
device. I should have some patches ready soon.


  parent reply	other threads:[~2016-12-21 23:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-20  6:00 BQ27xxx registers Chris Lapa
2016-12-20 11:34 ` Pali Rohár
2016-12-21  2:49   ` Chris Lapa
2016-12-21 12:46     ` Pali Rohár
2016-12-21 13:19       ` Sebastian Reichel
2016-12-21 23:37       ` Chris Lapa [this message]
2017-01-16 17:43         ` Andrew F. Davis
2017-01-17  4:47           ` Chris Lapa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).