mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Nirujogi, Pratap" <pnirujog@amd.com>
Cc: Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hao Yao <hao.yao@intel.com>,
	Pratap Nirujogi <pratap.nirujogi@amd.com>,
	mchehab@kernel.org, hverkuil@xs4all.nl,
	bryan.odonoghue@linaro.org, krzk@kernel.org,
	dave.stevenson@raspberrypi.com, hdegoede@redhat.com,
	jai.luthra@ideasonboard.com, tomi.valkeinen@ideasonboard.com,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	benjamin.chan@amd.com, bin.du@amd.com, grosikop@amd.com,
	king.li@amd.com, dantony@amd.com, vengutta@amd.com,
	dongcheng.yan@intel.com, jason.z.chen@intel.com,
	jimmy.su@intel.com, Svetoslav.Stoilov@amd.com,
	Yana.Zheleva@amd.com
Subject: Re: [PATCH v3 RESEND] media: i2c: Add OV05C10 camera sensor driver
Date: Thu, 26 Jun 2025 21:56:47 +0300	[thread overview]
Message-ID: <20250626185647.GA30016@pendragon.ideasonboard.com> (raw)
In-Reply-To: <f59e0cdd-e41a-4865-8f11-9508b598e6b7@amd.com>

On Thu, Jun 26, 2025 at 02:22:00PM -0400, Nirujogi, Pratap wrote:
> On 6/26/2025 8:23 AM, Laurent Pinchart wrote:
> > On Thu, Jun 26, 2025 at 12:11:27PM +0100, Kieran Bingham wrote:
> >> Quoting Nirujogi, Pratap (2025-06-25 23:06:01)
> >>> Hi Sakari, Hi Laurent,
> >>>
> >>> On 6/23/2025 5:55 PM, Nirujogi, Pratap wrote:
> >>> [...]
> >>>>>>> I think it can live in the driver for now. Given that the device uses
> >>>>>>> only 8 bits of register address, I would store the page number in bits
> >>>>>>> 15:8 instead of bits 31:24, as the CCI helpers do not make bits 27:24
> >>>>>>> available for driver-specific purpose.
> >>>>>>
> >>>>>> I'd use the CCI private bits, the driver uses page numbers up to 4 so 4
> >>>>>> bits are plenty for that. If we add pages to CCI later, this may be
> >>>>>> refactored then.
> >>>>>
> >>>>> That works too.
> >>>>>
> >>>> Thanks for your support. We will add the page number in the register
> >>>> address 15:8 or 11:8 and will update the implementation accordingly in
> >>>> the next version.
> >>>>
> >>> I would like to share the approach we are taking to implement the CCI
> >>> helpers that support page value. Could you please review the steps and
> >>> let us know if they make sense or if any adjustments are needed?
> >>>
> >>> 1: Add new macros to embed page value into the register address.
> >>>
> >>> Ex:
> >>> #define CCI_PAGE_REG8(x, p)             ((1 << CCI_REG_WIDTH_SHIFT) | (p <<
> >>> CCI_REG_PRIVATE_SHIFT) | (x))
> >>> #define CCI_PAGE_REG16(x, p)            ((2 << CCI_REG_WIDTH_SHIFT) | (p <<
> >>> CCI_REG_PRIVATE_SHIFT) | (x))
> >>>
> >>> 2: Create V4L2 CCI context. Initialize page control reg, current_page,
> >>> regmap etc.
> >>>
> >>> Ex:
> >>> struct v4l2_cci_ctx {
> >>>          struct mutex lock;
> >>>          struct regmap *map;
> >>>          s16 current_page;
> >>>          u8 page_ctrl_reg;
> >>> }
> >>>
> >>> 3: Introduce new CCI helpers - cci_pwrite() and cci_pread() to handle
> >>> register read-writes updating the page control register as necessary.
> >>
> >> Out of curiosity - but couldn't the existing cci_write and cci_read
> >> already be used by the users - and then the default behaviour is that
> >> the page isn't modified if there is no page_ctrl_reg - and by default
> >> CCI_REG() will simply have (initilised) as page 0 - so the pages will
> >> never change on those calls?
> >>
> >> Then the users can indeed define
> >>
> >> #define TEST_PATTERN_PAGE 5
> >> #define TEST_PATTERN_COLOUR_BARS BIT(3)
> >>
> >> #define MY_TEST_PATTERN_REG CCI_PAGE_REG8(0x33, TEST_PATTERN_PAGE)
> >>
> >> and can call
> >>   cci_write(regmap, MY_TEST_PATTERN_REG, TEST_PATTERN_COLOUR_BARS, &ret);
> >>
> >> with everything handled transparently ?
> >>
> >>
> >> Or do you envisage more complications with the types of pages that might
> >> be supportable ?
> >>
> >> (I perfectly understand if I'm wishing for an unreachable utopia -
> >> because I haven't considered something implicit about the page handling
> >> that I haven't yet used :D)
> > 
> > I don't think we should implement page support in the CCI helpers
> > themselves yet. We have too few drivers to look at to understand the
> > requirements. Instead, I would store the page number in the driver
> > private bits of the 32-bit address (that's bits 31:28), and add wrappers
> > around cci_read() and cci_write() to the OV05C10 driver that handles the
> > page configuration.
> > 
> > Once we'll have multiple drivers doing the same, it will be easier to
> > see what requirements they share, and move the feature to the CCI
> > helpers.
> 
> Thanks for clarifying. I agree it would be simple and safer approach too 
> to handle this way. We will add the following macros in v4l2-cci.h and 

Please add the macros to the driver instead, not to v4l2-cci.h. Once
multiple drivers will implement a similar mechanism we can study how to
generalize it.

> update the existing wrappers ov05c10_reg_write() / ov05c10_reg_read() in 
> the driver to retrieve the page and register values to call cci_write() 
> / cci_read(). We will add new wrappers too wherever necessary in the 
> driver (ex: wrapper for cci_multi_reg_write() on replacing CCI_REG8 with 
> CCI_PAGE_REG8)
> 
> #define CCI_PAGE_REG8(x, p)		((1 << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG16(x, p)		((2 << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG24(x, p)		((3 << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG32(x, p)		((4 << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG64(x, p)		((8 << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG16_LE(x, p)		(CCI_REG_LE | (2U << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG24_LE(x, p)		(CCI_REG_LE | (3U << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG32_LE(x, p)		(CCI_REG_LE | (4U << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_REG64_LE(x, p)		(CCI_REG_LE | (8U << CCI_REG_WIDTH_SHIFT) | (p << CCI_REG_PAGE_SHIFT) | (x))
> #define CCI_PAGE_GET(x)			FIELD_GET(CCI_REG_PAGE_MASK, x)
> 
> >>> int cci_pwrite(void *data, u32 reg, u64 val, int *err)
> >>> {
> >>>          /* get v4l2_cci_ctx context from data */
> >>>
> >>>          /* get page value from reg */
> >>>
> >>>          /* acquire mutex */
> >>>
> >>>          /* update cci page control reg, save current page value */
> >>>
> >>>          /* do cci_write */
> >>>
> >>>          /* release mutex */
> >>> }
> >>>
> >>> Similar steps for cci_pread() as well.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2025-06-26 18:57 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-09 19:42 Pratap Nirujogi
2025-06-13  4:55 ` Hao Yao
2025-06-13 11:02   ` Kieran Bingham
2025-06-13 12:05     ` Bryan O'Donoghue
2025-06-16 23:15       ` Nirujogi, Pratap
2025-06-16 23:46     ` Nirujogi, Pratap
2025-06-28 19:23       ` Sakari Ailus
2025-06-13 22:02   ` Sakari Ailus
2025-06-14 22:52     ` Laurent Pinchart
2025-06-16 22:33       ` Nirujogi, Pratap
2025-06-29  7:40         ` Sakari Ailus
2025-06-30 22:31           ` Nirujogi, Pratap
2025-07-02  6:08             ` Yan, Dongcheng
2025-07-02  6:12               ` Sakari Ailus
2025-07-02 16:47                 ` Nirujogi, Pratap
2025-07-03  6:24                   ` Yan, Dongcheng
2025-07-05 11:45                     ` Nirujogi, Pratap
2025-07-06  9:11                   ` Sakari Ailus
2025-07-08 15:31                     ` Nirujogi, Pratap
2025-06-23 11:27       ` Sakari Ailus
2025-06-23 12:06         ` Laurent Pinchart
2025-06-23 21:53           ` Nirujogi, Pratap
2025-06-23 22:11             ` Laurent Pinchart
2025-06-16 23:12     ` Nirujogi, Pratap
2025-06-23 12:09       ` Laurent Pinchart
2025-06-23 13:22         ` Sakari Ailus
2025-06-23 13:42           ` Laurent Pinchart
2025-06-23 21:55             ` Nirujogi, Pratap
2025-06-23 22:06               ` Laurent Pinchart
2025-06-23 23:21                 ` Nirujogi, Pratap
2025-06-25 22:06               ` Nirujogi, Pratap
2025-06-26 11:11                 ` Kieran Bingham
2025-06-26 12:23                   ` Laurent Pinchart
2025-06-26 18:22                     ` Nirujogi, Pratap
2025-06-26 18:56                       ` Laurent Pinchart [this message]
2025-06-26 19:21                         ` Nirujogi, Pratap
2025-06-26 18:14                   ` Nirujogi, Pratap
2025-06-17  0:19   ` Nirujogi, Pratap
2025-06-15  0:09 ` Laurent Pinchart
2025-06-16 22:49   ` Nirujogi, Pratap
2025-06-23 21:51     ` Nirujogi, Pratap
2025-06-23 22:05       ` Laurent Pinchart
2025-06-23 23:28         ` Nirujogi, Pratap
2025-06-24  0:19           ` Laurent Pinchart
2025-06-24 18:49             ` Nirujogi, Pratap
2025-06-24 19:00               ` Laurent Pinchart
2025-06-24 19:49                 ` Nirujogi, Pratap
2025-06-24  8:35         ` Mehdi Djait
2025-06-24 10:19           ` Sakari Ailus
2025-06-24 10:20             ` Sakari Ailus
2025-06-24 10:27               ` Laurent Pinchart
2025-06-24 11:27                 ` Mehdi Djait
2025-06-24 11:33                   ` Laurent Pinchart
2025-06-24 11:46                   ` Sakari Ailus
2025-06-24 16:34                     ` Mehdi Djait
2025-06-24 20:24                       ` Nirujogi, Pratap
2025-06-25  6:11                       ` Sakari Ailus
2025-06-24 18:26                   ` Nirujogi, Pratap
2025-06-24 20:01                     ` Nirujogi, Pratap
  -- strict thread matches above, loose matches on Subject: below --
2025-05-15 22:41 Pratap Nirujogi

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=20250626185647.GA30016@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=Svetoslav.Stoilov@amd.com \
    --cc=Yana.Zheleva@amd.com \
    --cc=benjamin.chan@amd.com \
    --cc=bin.du@amd.com \
    --cc=bryan.odonoghue@linaro.org \
    --cc=dantony@amd.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dongcheng.yan@intel.com \
    --cc=grosikop@amd.com \
    --cc=hao.yao@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=jai.luthra@ideasonboard.com \
    --cc=jason.z.chen@intel.com \
    --cc=jimmy.su@intel.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=king.li@amd.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=pnirujog@amd.com \
    --cc=pratap.nirujogi@amd.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=vengutta@amd.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

all inboxes | Powered by JetHome®