[v3,0/3] media: i2c: ov5640 feature enhancement and fixes

Hi All,

This patch series fixes DVP support and enables BT656 mode in
the driver.

Cheers,
Prabhakar

Changes for v3:
* Dropped DT binding patch
* Fail probe if unsupported bus_type is passed
* Fixed review comments pointed by Jacopo

Changes for v2:
* Added support to fallback in parallel mode
* Documented bus-type property
* Added descriptive commit message for patch 2/4 as pointed
  by Sakari
* Fixed review comments pointed by Laurent to have separate functions
  for mipi and dvp setup
* Made sure the sensor is in power down mode during startup too for
  DVP mode

Lad Prabhakar (3):
  media: i2c: ov5640: Enable data pins on poweron for DVP mode
  media: i2c: ov5640: Add support for BT656 mode
  media: i2c: ov5640: Fail probe on unsupported bus_type

 drivers/media/i2c/ov5640.c | 340 +++++++++++++++++++++----------------
 1 file changed, 196 insertions(+), 144 deletions(-)

Hi Prabhakar,

My apologies for the late reply.

On Thu, Aug 13, 2020 at 06:13:35PM +0100, Lad Prabhakar wrote:
> During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP
> mode with rcar-vin bridge noticed the capture worked fine for the first run
> (with yavta), but for subsequent runs the bridge driver waited for the
> frame to be captured. Debugging further noticed the data lines were
> enabled/disabled in stream on/off callback and dumping the register
> contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct
> values, but yet frame capturing failed.
> 
> To get around this issue the following actions are performed for
> parallel mode (DVP):
> 1: Keeps the sensor in software power down mode and is woken up only in
>    ov5640_set_stream_dvp() callback.

I'd suppose with s_power, the main driver would power the device off
when it's not streaming.

> 2: Enables data lines in s_power callback
> 3: Configures HVP lines in s_power callback instead of configuring
>    everytime in ov5640_set_stream_dvp().
> 4: Disables MIPI interface.

Could you split this into two (or even more) patches so that the first
refactors the receiver setup and another one changes how it actually works?
That way this would be quite a bit easier to review.

While some of the above seem entirely reasonable, the changes are vast and
testing should be done on different boards to make sure things won't break.
That said, this depends on others who have the hardware.

Hi Prabhakar, Sakari,

On Wed, Sep 02, 2020 at 01:10:53AM +0300, Sakari Ailus wrote:
> Hi Prabhakar,
>
> My apologies for the late reply.
>
> On Thu, Aug 13, 2020 at 06:13:35PM +0100, Lad Prabhakar wrote:
> > During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP
> > mode with rcar-vin bridge noticed the capture worked fine for the first run
> > (with yavta), but for subsequent runs the bridge driver waited for the
> > frame to be captured. Debugging further noticed the data lines were
> > enabled/disabled in stream on/off callback and dumping the register
> > contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct
> > values, but yet frame capturing failed.
> >
> > To get around this issue the following actions are performed for
> > parallel mode (DVP):
> > 1: Keeps the sensor in software power down mode and is woken up only in
> >    ov5640_set_stream_dvp() callback.
>
> I'd suppose with s_power, the main driver would power the device off
> when it's not streaming.
>
> > 2: Enables data lines in s_power callback
> > 3: Configures HVP lines in s_power callback instead of configuring
> >    everytime in ov5640_set_stream_dvp().
> > 4: Disables MIPI interface.
>
> Could you split this into two (or even more) patches so that the first
> refactors the receiver setup and another one changes how it actually works?
> That way this would be quite a bit easier to review.
>
> While some of the above seem entirely reasonable, the changes are vast and
> testing should be done on different boards to make sure things won't break.
> That said, this depends on others who have the hardware.

I left it as a comment during review of v2, but now more formally:

For CSI-2 capture operations:
Tested-by: Jacopo Mondi <jacopo@jmondi.org>

Thanks
  j

>
> --
> Kind regards,
>
> Sakari Ailus