linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To: Lee Jones <lee.jones@linaro.org>,
	Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Support Opensource <Support.Opensource@diasemi.com>
Subject: RE: [RESEND PATCH 1/2] mfd: da9063: Fix revision handling to correctly select reg tables
Date: Mon, 24 Feb 2020 11:08:51 +0000	[thread overview]
Message-ID: <AM6PR10MB22638EDDDDFABB34D0DFC21B80EC0@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20200224095654.GI3494@dell>

On 24 February 2020 09:57, Lee Jones wrote:

> On Fri, 24 Jan 2020, Adam Thomson wrote:
> 
> > The current implementation performs checking in the i2c_probe()
> > function of the variant_code but does this immediately after the
> > containing struct has been initialised as all zero. This means the
> > check for variant code will always default to using the BB tables
> > and will never select AD. The variant code is subsequently set
> > by device_init() and later used by the RTC so really it's a little
> > fortunate this mismatch works.
> >
> > This update creates an initial temporary regmap instantiation to
> > simply read the chip and variant/revision information (common to
> > all revisions) so that it can subsequently correctly choose the
> > proper regmap tables for real initialisation.
> 
> IIUC, you have a dependency issue whereby the device type is required
> before you can select the correct Regmap configuration.  Is that
> correct?

Yep, spot on.

> 
> If so, using Regmap for the initial register reads sounds like
> over-kill.  What's stopping you simply using raw reads before the
> Regmap is instantiated?

Actually nothing and I did consider this at the start. Nice thing with regmap
is it's all tidily contained and provides the page swapping mechanism to access
higher page registers like the variant information. Given this is only once at
probe time it felt like this was a reasonable solution. However if you're not
keen I can update to use raw access instead.

> 
> > Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
> > ---
> >  drivers/mfd/da9063-core.c            |  31 -------
> >  drivers/mfd/da9063-i2c.c             | 167 +++++++++++++++++++++++++++++++-
> ---
> >  include/linux/mfd/da9063/registers.h |  15 ++--
> >  3 files changed, 160 insertions(+), 53 deletions(-)
> 
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-02-24 11:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 11:25 [RESEND PATCH 0/2] Resolve revision handling and add support for DA silicon Adam Thomson
2020-01-24 11:25 ` [RESEND PATCH 1/2] mfd: da9063: Fix revision handling to correctly select reg tables Adam Thomson
2020-02-24  9:56   ` Lee Jones
2020-02-24 11:08     ` Adam Thomson [this message]
2020-02-24 11:27       ` Lee Jones
2020-02-24 12:11         ` Adam Thomson
2020-02-25  9:00           ` Lee Jones
2020-02-25 10:08             ` Adam Thomson
2020-01-24 11:25 ` [RESEND PATCH 2/2] mfd: da9063: Add support for latest DA silicon revision Adam Thomson
2020-02-24  9:58   ` Lee Jones

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=AM6PR10MB22638EDDDDFABB34D0DFC21B80EC0@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM \
    --to=adam.thomson.opensource@diasemi.com \
    --cc=Support.Opensource@diasemi.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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