Linux Media Controller development
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Andy Shevchenko <andy@kernel.org>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 2/3] media: atomisp: ov2680: Convert to new CCI register access helpers
Date: Wed, 7 Jun 2023 17:59:08 +0200	[thread overview]
Message-ID: <3dd04737-8c9d-d359-9a6e-919fe34d1674@redhat.com> (raw)
In-Reply-To: <20230607155115.GF22127@pendragon.ideasonboard.com>

Hi Laurent,

On 6/7/23 17:51, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Wed, Jun 07, 2023 at 10:53:54AM +0200, Hans de Goede wrote:
>> On 6/6/23 22:53, Andy Shevchenko wrote:
>>> On Tue, Jun 6, 2023 at 7:58 PM Hans de Goede wrote:
>>>>
>>>> Use the new comon CCI register access helpers to replace the private
>>>> register access helpers in the ov2680 driver.
>>>>
>>>> While at it also switch to using the same register address defines
>>>> as the standard drivers/media/i2c/ov2680.c driver to make merging
>>>> the 2 drivers simpler.
>>>
>>> ...
>>>
>>>> +       cci_write(sensor->regmap, OV2680_REG_SENSOR_CTRL_0A, sensor_ctrl_0a, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_HORIZONTAL_START, sensor->mode.h_start, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_VERTICAL_START, sensor->mode.v_start, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_HORIZONTAL_END, sensor->mode.h_end, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_VERTICAL_END, sensor->mode.v_end, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_HORIZONTAL_OUTPUT_SIZE,
>>>> +                 sensor->mode.h_output_size, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_VERTICAL_OUTPUT_SIZE,
>>>> +                 sensor->mode.v_output_size, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_TIMING_HTS, sensor->mode.hts, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_TIMING_VTS, sensor->mode.vts, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_ISP_X_WIN, 0, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_ISP_Y_WIN, 0, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_X_INC, inc, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_Y_INC, inc, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_X_WIN, sensor->mode.h_output_size, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_Y_WIN, sensor->mode.v_output_size, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_FORMAT1, fmt1, &ret);
>>>> +       cci_write(sensor->regmap, OV2680_REG_FORMAT2, fmt2, &ret);
>>>
>>> I know that &ret thingy was discussed before and Laurent is keen to
>>> have this, but has anybody actually tested how bad or not at all the
>>> code generation becomes?
>>
>> The cci_write function is in another module, so it won't be inlined
>> and as such I don't see how the code generation can become bad. We
>> loose all the if (ret) return ret; checks here, so the code should
>> become smaller.
>>
>> Or are you worried about having to pass the 1 extra parameter ?
>>
>>> ...
>>>
>>>> +       struct device *dev;
>>>> +       struct regmap *regmap;
>>>
>>> Isn't the same device associated with regmap? If so, one of them
>>> probably duplicates the other.
>>
>> You are right, but the entire atomisp-ov2680.c file is going away real
>> soon now. I plan to post a series to get drivers/media/i2c/ov2680.c
>> ready to replace it later today.
>>
>> So I'm not even sure if this patch should be merged, as I mentioned in
>> the cover letter this one is mostly here to illustrate use of the new
>> helpers.
> 
> How about porting drivers/media/i2c/imx290.c ? That's a real-life
> example that can be merged, which is good to serve as an example
> showcasing the API usage in mainline. It will also help ensuring that
> these helpers are a good fit for drivers that already encode the
> register width in the macros.

I prefer to port over drivers which I can actually test,
at least for now.

I already have converting ov5693.c (which also already has macros
to encode to width) on my TODO list. I'll convert that for v2
of the series.

And I also have a conversion of the "main" drivers/media/i2c/ov2680.c
ready.

I'll post that conversion as part of my big main ov2680 changes series
which I'll post in a couple of minutes (just need to write
a cover letter and then its ready).

Regards,

Hans



 
>> I also wrote this patch to make porting recent atomisp-ov2680.c
>> changes over to drivers/media/i2c/ov2680.c easier. Part of the series
>> to get drivers/media/i2c/ov2680.c into shape is converting it to the
>> new CCI helpers so that I could then easily copy over bits from the
>> also converted atomisp-ov2680.c.
>>
>> So it might be interesting to still merge this so that the latest
>> state of atomisp-ov2680.c is easier to compare to
>> drivers/media/i2c/ov2680.c if the need arises.
> 




  reply	other threads:[~2023-06-07 16:00 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
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 [this message]
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=3dd04737-8c9d-d359-9a6e-919fe34d1674@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=laurent.pinchart@ideasonboard.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