lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200901221052.GC32646@paasikivi.fi.intel.com>
Date:   Wed, 2 Sep 2020 01:10:53 +0300
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Cc:     Steve Longerbeam <slongerbeam@...il.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Paul <paul.kocialkowski@...tlin.com>,
        Hugues Fruchet <hugues.fruchet@...com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org,
        Prabhakar <prabhakar.csengg@...il.com>
Subject: Re: [PATCH v3 1/3] media: i2c: ov5640: Enable data pins on poweron
 for DVP mode

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.

-- 
Kind regards,

Sakari Ailus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ