From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
David Laight <David.Laight@aculab.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v4 6/7] gpio: exar: switch to using regmap
Date: Tue, 10 Nov 2020 18:12:25 +0200 [thread overview]
Message-ID: <20201110161225.GZ4077@smile.fi.intel.com> (raw)
In-Reply-To: <CAMRc=MfsLc_DKuCaOwq-xDjT0V8yk3rGt8buJ9qgbGNj25youA@mail.gmail.com>
On Tue, Nov 10, 2020 at 04:12:38PM +0100, Bartosz Golaszewski wrote:
> On Tue, Nov 10, 2020 at 4:09 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Tue, Nov 10, 2020 at 05:04:47PM +0200, Andy Shevchenko wrote:
> > > On Tue, Nov 10, 2020 at 03:55:51PM +0100, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > > >
> > > > We can simplify the code in gpio-exar by using regmap. This allows us to
> > > > drop the mutex (regmap provides its own locking) and we can also reuse
> > > > regmap's bit operations instead of implementing our own update function.
> > >
> > > ...
> > >
> > > > +static const struct regmap_config exar_regmap_config = {
> > > > + .name = "exar-gpio",
> > > > + .reg_bits = 16,
> > >
> > > As per previous version comment.
> > >
> > > Hold on, the registers are 16-bit wide, but their halves are sparsed!
> > > So, I guess 8 and 8 with helpers to get hi and lo parts are essential.
> > >
> > >
> > > TABLE 5: DEVICE CONFIGURATION REGISTERS SHOWN IN BYTE ALIGNMENT
> > >
> > > > + .val_bits = 8,
> > > > +};
> > >
> > > This is basically represents two banks out of 6 8-bit registers each.
> >
> > ...which makes me wonder if gpio-regmap can be utilized here...
> >
>
> But the address width won't affect the actuall accessing of 8 bits
> registers in an mmio regmap. Internally the mmio regmap does pretty
> much the same thing the previous driver did: call readb()/writeb() on
> 8-bit "chunks" of the banks.
It will affect reg dump in debugfs. I would really narrow down the register
address space in the config, otherwise that debugfs facility will screw up a
lot of things.
So, and to be on pedantic side...
"The Device Configuration Registers and the two individual UART Configuration
Registers of the XR17V352 occupy 2K of PCI bus memory address space."
11 seems the correct value for the address width.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-11-10 16:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 14:55 [PATCH v4 0/7] gpio: exar: refactor the driver Bartosz Golaszewski
2020-11-10 14:55 ` [PATCH v4 1/7] gpio: exar: add a newline after the copyright notice Bartosz Golaszewski
2020-11-10 14:55 ` [PATCH v4 2/7] gpio: exar: include idr.h Bartosz Golaszewski
2020-11-10 14:55 ` [PATCH v4 3/7] gpio: exar: switch to a simpler IDA interface Bartosz Golaszewski
2020-11-10 14:55 ` [PATCH v4 4/7] gpio: exar: use a helper variable for &pdev->dev Bartosz Golaszewski
2020-11-10 14:55 ` [PATCH v4 5/7] gpio: exar: unduplicate address and offset computation Bartosz Golaszewski
2020-11-10 14:55 ` [PATCH v4 6/7] gpio: exar: switch to using regmap Bartosz Golaszewski
2020-11-10 15:04 ` Andy Shevchenko
2020-11-10 15:10 ` Andy Shevchenko
2020-11-10 15:12 ` Bartosz Golaszewski
2020-11-10 16:12 ` Andy Shevchenko [this message]
2020-11-10 16:36 ` Bartosz Golaszewski
2020-11-10 16:44 ` Andy Shevchenko
2020-11-10 16:52 ` Bartosz Golaszewski
2020-11-10 17:08 ` Andy Shevchenko
2020-11-10 14:55 ` [PATCH v4 7/7] gpio: exar: use devm action for freeing the IDA and drop remove() Bartosz Golaszewski
2020-11-10 15:07 ` [PATCH v4 0/7] gpio: exar: refactor the driver Andy Shevchenko
2020-11-10 16:19 ` Andy Shevchenko
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=20201110161225.GZ4077@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=David.Laight@aculab.com \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=jan.kiszka@siemens.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.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