From: "Nirujogi, Pratap" <pnirujog@amd.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: 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 14:22:00 -0400 [thread overview]
Message-ID: <f59e0cdd-e41a-4865-8f11-9508b598e6b7@amd.com> (raw)
In-Reply-To: <20250626122306.GI8738@pendragon.ideasonboard.com>
Hi Laurent,
On 6/26/2025 8:23 AM, Laurent Pinchart wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> 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
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)
Thanks,
Pratap
>>> 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
next prev parent reply other threads:[~2025-06-26 18:22 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 [this message]
2025-06-26 18:56 ` Laurent Pinchart
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=f59e0cdd-e41a-4865-8f11-9508b598e6b7@amd.com \
--to=pnirujog@amd.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=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--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®