All of lore.kernel.org
 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: Tue, 25 Feb 2020 10:08:03 +0000	[thread overview]
Message-ID: <AM6PR10MB2263116205FAAE470E1F23C380ED0@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20200225090020.GX3494@dell>

On 25 February 2020 09:00, Lee Jones wrote:

> On Mon, 24 Feb 2020, Adam Thomson wrote:
> 
> > On 24 February 2020 11:27, Lee Jones wrote:
> >
> > > On Mon, 24 Feb 2020, Adam Thomson wrote:
> > >
> > > > 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.
> > >
> > > It would be nice to compare the 2 solutions side by side.  I can't see
> > > the raw reads of a few device-ID registers being anywhere near 170
> > > lines though.
> >
> > To be fair the regmap specific additions for the temporary register access, are
> > maybe 50 - 60 lines. The rest is to do with handling the result which you'll
> > need anyway to select the correct register map. I reckon to provide raw read
> and
> > write access we're going to probably be similar or more as we'll need to write
> > the page register then read from the relevant ID registers. Using this an
> > example for the lines count:
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/mfd/tps6507x.c#L37
> 
> Ah, they are I2C transactions?  Not the nice readl()s I had in mind.

Yes, I2C register access so needs more work.

> 
> > I can knock something together though just to see what it looks like.
> 
> Well, I'd appreciated that, thanks.

No problem, I'll try and get something back soon.

  reply	other threads:[~2020-02-25 10: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
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 [this message]
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=AM6PR10MB2263116205FAAE470E1F23C380ED0@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.