Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200916160552.1062243-1-ribalda@kernel.org> <20200916162824.GC6374@sirena.org.uk>
 <CAPybu_20oay941cqHqa_D13cN0XCrk=Pa113ZuwbbAuVC3yX3A@mail.gmail.com> <20200917112203.GB4755@sirena.org.uk>
In-Reply-To: <20200917112203.GB4755@sirena.org.uk>
From:   Ricardo Ribalda Delgado <ribalda@kernel.org>
Date:   Thu, 17 Sep 2020 13:38:53 +0200
Message-ID: <CAPybu_2L5eK7SckELHxUsW72TZ8kG0TsTHbSn1Z6ohyUaPzQCg@mail.gmail.com>
Subject: Re: [PATCH] regmap: Add support for 12/20 register formatting
To:     Mark Brown <broonie@kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

HI Mark

On Thu, Sep 17, 2020 at 1:22 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > What exactly is the format you're trying to describe here?  It sounds
> > > like there's two blocks of padding in here (I'm assuing that's what
> > > dummy means) but what's the exact arrangement here and what are the
> > > commands?  It sounds like this might not work ideally with things like
> > > the cache code (if it makes things seems sparser than they are) and
> > > might not be obvious to someone looking at the datsheet.
>
> > The format is
>
> > XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
>
> > Where X is dont care, C is command, A is address and D is data bits. I
>
> > Shall I add this to the commit message? I want to send a V2 anyway,
> > because I screwed up the identity (ribalda.com instead of kernel.org)
>
> Yes, please.  I was fairly sure it worked, it was just a question of if
> it was ideal for the format described.  The only issue I can see with
> the above is that the users will need to left shift their data - on the
> face of it it would seem better to add a facility for padding the LSBs
> of the data field to the core so that users can just use the data field
> as documented.

I was thinking also about that, the problem is that there are many
devices on that family that are "software" compatible and it only
changes the width of the data. Eg:

DDDDDDDDDDDDDDDDXXXX
DDDDDDDDDDDDXXXXXXXX
DDDDDDDDXXXXXXXXXXXX

So if we need to make a driver, we could use the same driver for all
the chips on that family, saying to the user that the data size is
always 20 bits....

I will send v2 ASAP with the updated doc.

Thanks