From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH 1/3] media: Add MIPI CCI register access helper functions
Date: Wed, 7 Jun 2023 17:55:38 +0300 [thread overview]
Message-ID: <20230607145538.GB22127@pendragon.ideasonboard.com> (raw)
In-Reply-To: <ZIBxhg1LVL8+zBCE@kekkonen.localdomain>
Hello,
On Wed, Jun 07, 2023 at 12:01:10PM +0000, Sakari Ailus wrote:
> On Wed, Jun 07, 2023 at 10:40:34AM +0200, Hans de Goede wrote:
> > On 6/6/23 22:43, Andy Shevchenko wrote:
> > > On Tue, Jun 6, 2023 at 7:58 PM Hans de Goede wrote:
> > >>
> > >> The CSI2 specification specifies a standard method to access camera sensor
> > >> registers called "Camera Control Interface (CCI)".
> > >>
> > >> This uses either 8 or 16 bit (big-endian wire order) register addresses
> > >> and supports 8, 16, 24 or 32 bit (big-endian wire order) register widths.
> > >>
> > >> Currently a lot of Linux camera sensor drivers all have their own custom
> > >> helpers for this, often copy and pasted from other drivers.
> > >>
> > >> Add a set of generic helpers for this so that all sensor drivers can
> > >> switch to a single common implementation.
> > >>
> > >> These helpers take an extra optional "int *err" function parameter,
> > >> this can be used to chain a bunch of register accesses together with
> > >> only a single error check at the end, rather then needing to error
> > >> check each individual register access. The first failing call will
> > >> set the contents of err to a non 0 value and all other calls will
> > >> then become no-ops.
> > >
> > > ...
> > >
> > >> +#include <linux/delay.h>
> > >> +#include <linux/dev_printk.h>
> > >> +#include <linux/module.h>
> > >> +#include <linux/regmap.h>
> > >
> > > + types.h
> > >
> > >> +#include <media/v4l2-cci.h>
> > >
> > >> +int cci_read(struct regmap *map, u32 reg, u32 *val, int *err)
> > >> +{
> > >> + int i, len, ret;
> > >> + u8 buf[4];
> > >> +
> > >> + if (err && *err)
> > >> + return *err;
> > >> +
> > >> + /* Set len to register width in bytes */
> > >> + len = ((reg & CCI_REG_WIDTH_MASK) >> CCI_REG_WIDTH_SHIFT) + 1;
> > >> + reg &= CCI_REG_ADDR_MASK;
> > >> +
> > >> + ret = regmap_bulk_read(map, reg, buf, len);
> > >> + if (ret) {
> > >> + dev_err(regmap_get_device(map), "Error reading reg 0x%4x: %d\n", reg, ret);
> > >> + if (err)
> > >> + *err = ret;
> > >> +
> > >> + return ret;
> > >> + }
> > >> +
> > >> + *val = 0;
> > >> + for (i = 0; i < len; i++) {
> > >> + *val <<= 8;
> > >> + *val |= buf[i];
> > >> + }
> > >
> > > I really prefer to see put_unaligned() here depending on the length.
> > > Note, that on some CPUs it might be one assembly instruction or even
> > > none, depending on how the result is going to be used.
> >
> > Ok, so you mean changing it to something like this:
> >
> > switch (len)
> > case 1:
> > *val = buf[0];
> > break;
> > case 2:
> > *val = get_unaligned_be16(buf);
> > break;
> > case 3:
> > *val = __get_unaligned_be24(buf);
> > break;
> > case 4:
> > *val = get_unaligned_be32(buf);
> > break;
> > }
>
> I think the loop looks nicer but I'm fine with this as well.
>
> > ?
> >
> > >> + return 0;
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(cci_read);
> > >
> > > Can we have it namespaced?
> >
> > I'm not sure if having just these 5 symbols in their own namespace
> > is worth it. SO far the media subsystem is not using module/symbol
> > namespacing at all.
> >
> > Sakari, Laurent, any opinions on this ?
>
> Regmap nor V4L2 use it so I wouldn't use it here either.
Ditto.
> > >> +int cci_write(struct regmap *map, u32 reg, u32 val, int *err)
> > >> +{
> > >> + int i, len, ret;
> > >> + u8 buf[4];
> > >> +
> > >> + if (err && *err)
> > >> + return *err;
> > >> +
> > >> + /* Set len to register width in bytes */
> > >> + len = ((reg & CCI_REG_WIDTH_MASK) >> CCI_REG_WIDTH_SHIFT) + 1;
> > >> + reg &= CCI_REG_ADDR_MASK;
> > >> +
> > >> + for (i = 0; i < len; i++) {
> > >> + buf[len - i - 1] = val & 0xff;
> > >> + val >>= 8;
> > >> + }
> > >> +
> > >> + ret = regmap_bulk_write(map, reg, buf, len);
> > >> + if (ret) {
> > >> + dev_err(regmap_get_device(map), "Error writing reg 0x%4x: %d\n", reg, ret);
> > >> + if (err)
> > >> + *err = ret;
> > >> + }
> > >> +
> > >> + return ret;
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(cci_write);
> > >
> > > Same comments as per above function.
> > >
> > > ...
> > >
> > >> + if (regs[i].delay_us)
> > >
> > > I'm wondering why fsleep() doesn't have this check? Or does it?
> > >
> > >> + fsleep(regs[i].delay_us);
> > >
> > > ...
> > >
> > >> +struct regmap *cci_regmap_init_i2c(struct i2c_client *client, int reg_addr_bits)
> > >> +{
> > >> + struct regmap_config config = {
> > >> + .reg_bits = reg_addr_bits,
> > >> + .val_bits = 8,
> > >> + .reg_format_endian = REGMAP_ENDIAN_BIG,
> > >
> > > Is the lock required?
> > > If so, how is it helpful?
> >
> > Interesting questions sensor drivers typically already do
> > their own locking.
> >
> > So I guess we could indeed tell regmap to skip locking here.
> >
> > Sakari, Laurent any opinion on this ?
>
> There are loops here so it won't be atomic in any case.
>
> Generally drivers indeed already take care of this. I don't think we need
> locking on this level.
Agreed.
> > > Can we move this outside as static const?
> >
> > No, because reg_bits is not const.
> >
> > >> + };
> > >> +
> > >> + return devm_regmap_init_i2c(client, &config);
> > >> +}
> > >
> > > ...
> > >
> > >> +#ifndef _V4L2_CCI_H
> > >> +#define _V4L2_CCI_H
> > >
> > > + bits.h
> > >
> > >> +#include <linux/regmap.h>
> > >
> > > Not used, rather requires forward declarations of
> > >
> > > struct regmap
> > > struct reg_sequence
> >
> > Ack, I'll change this for the next version.
> >
> > > Also note missing i2c_client forward declaration.
> >
> > That was also taken care of by regmap.h.
> >
> > >> +#include <linux/types.h>
> > >> +
> > >> +/*
> > >> + * Note cci_reg_8 deliberately is 0, not 1, so that raw
> > >> + * (not wrapped in a CCI_REG*() macro) register addresses
> > >> + * do 8 bit wide accesses. This allows unchanged use of register
> > >> + * initialization lists of raw address, value pairs which only
> > >> + * do 8 bit width accesses. Which makes porting drivers easier.
> > >> + */
> > >> +enum cci_reg_type {
> > >> + cci_reg_8 = 0,
> > >
> > > But this is guaranteed by the C standard... See also below.
> > >
> > >> + cci_reg_16,
> > >
> > > But this one becomes 1, so the above comment doesn't clarify why it's
> > > okay to have it 1 and not 2.
> >
> > Basically the idea is that the enum value is the reg-width in bytes - 1
> > where the - 1 is there so that cci_reg_8 = 0 .
>
> I'm fine with the comment.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2023-06-07 14:55 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 16:58 [PATCH 0/3] media: Add MIPI CCI register access helper functions Hans de Goede
2023-06-06 16:58 ` [PATCH 1/3] " Hans de Goede
2023-06-06 20:43 ` Andy Shevchenko
2023-06-07 8:40 ` Hans de Goede
2023-06-07 12:01 ` Sakari Ailus
2023-06-07 14:55 ` Laurent Pinchart [this message]
2023-06-07 15:40 ` Andy Shevchenko
2023-06-07 15:58 ` Hans de Goede
2023-06-07 16:14 ` Andy Shevchenko
2023-06-07 16:20 ` Hans de Goede
2023-06-07 18:03 ` Andy Shevchenko
2023-06-07 7:50 ` Sakari Ailus
2023-06-07 8:46 ` Hans de Goede
2023-06-07 11:41 ` Sakari Ailus
2023-06-07 18:18 ` Laurent Pinchart
2023-06-07 19:01 ` Hans de Goede
2023-06-07 20:07 ` Andy Shevchenko
2023-06-08 8:33 ` Hans de Goede
2023-06-08 8:33 ` Sakari Ailus
2023-06-08 10:24 ` Andy Shevchenko
2023-06-08 10:27 ` Laurent Pinchart
2023-06-08 11:01 ` Sakari Ailus
2023-06-12 15:03 ` Laurent Pinchart
2023-06-13 9:57 ` Sakari Ailus
2023-06-12 13:48 ` Hans de Goede
2023-06-12 15:16 ` Laurent Pinchart
2023-06-12 15:33 ` Hans de Goede
2023-06-12 16:02 ` Laurent Pinchart
2023-06-06 16:58 ` [PATCH 2/3] media: atomisp: ov2680: Convert to new CCI register access helpers Hans de Goede
2023-06-06 20:53 ` Andy Shevchenko
2023-06-07 8:53 ` Hans de Goede
2023-06-07 15:51 ` Laurent Pinchart
2023-06-07 15:59 ` Hans de Goede
2023-06-07 16:07 ` Laurent Pinchart
2023-06-07 16:05 ` Laurent Pinchart
2023-06-07 16:18 ` Hans de Goede
2023-06-06 16:58 ` [PATCH 3/3] media: Remove ov_16bit_addr_reg_helpers.h Hans de Goede
2023-06-07 15:57 ` Laurent Pinchart
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=20230607145538.GB22127@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=andy.shevchenko@gmail.com \
--cc=andy@kernel.org \
--cc=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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