linux-kernel - Re: [PATCH 04/14] media: sun4i-csi: Fix [HV]sync polarity handling

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] [day] [month] [year] [list]

Message-ID: <CAHdV42W58Q_ciCmd5bmoX32KpKCKOh1iuGOE5f-=yc_WOJ=A+g@mail.gmail.com>
Date:   Mon, 16 Jan 2023 21:43:05 +0300
From:   Oleg Verych <olecom@...il.com>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     wens@...nel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, mark.rutland@....com,
        mchehab@...nel.org, robh+dt@...nel.org,
        sakari.ailus@...ux.intel.com, wens@...e.org
Subject: Re: [PATCH 04/14] media: sun4i-csi: Fix [HV]sync polarity handling

Hi!

On 1/16/23, Maxime Ripard <maxime@...no.tech> wrote:
> Hi,
>
> On Mon, Jan 16, 2023 at 01:03:59PM +0300, Oleg Verych wrote:
>> > -	hsync_pol = !!(bus->flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH);
>> > -	vsync_pol = !!(bus->flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH);
>> > +	/*
>> > +	 * This hardware uses [HV]REF instead of [HV]SYNC. Based on the
>> > +	 * provided timing diagrams in the manual, positive polarity
>> > +	 * equals active high [HV]REF.
>> > +	 *
>> > +	 * When the back porch is 0, [HV]REF is more or less equivalent
>> > +	 * to [HV]SYNC inverted.
>> > +	 */
>> > +	href_pol = !!(bus->flags & V4L2_MBUS_HSYNC_ACTIVE_LOW);
>> > +	vref_pol = !!(bus->flags & V4L2_MBUS_VSYNC_ACTIVE_LOW);
>>
>> After this change has been made there is a need of explicit explanation
>> of what "Active high" / "Active low" in dts really mean.
>
> Why?

It will be better understood by a person behind an oscilloscope who is
trying to figure out the logic behind dts, csi driver, csi controller,
wire voltage levels by just reading device tree definitions. Because
dts must be changed in order to connect source / sink devices.

>
> I'm sorry, it's not clear to me what is confusing in those excerpts?

I'm sorry too, maybe that is not clear. Confusion is here:

>> > +                        hsync-active = <1>; /* Active high */
>>
>> original CSI driver

i.e. <1> - active high

>> > +			hsync-active = <0>; /* Active high */
>>
>> this change patchset

i.e. <0> - active high

>> > +				hsync-active = <1>; /* Active high */
>>
>> this patcheset

i.e. <1> - active high


>> Currently physical high/low voltage levels are like that:
>> (I'm not sure about vsync-active)
>>
>> * hsync-active = <0>; /* HSYNC active 'low' => wire active is 'high' */
>
> Yes
>
>>   CSI register setting: href_pol: 1,
>
> Not really, no. It's what this patch commit log is saying: HREF is
> !HSYNC, so in order to get a hsync pulse active high, you need to set
> href_pol to 0.

I'm totally confused here. That `hsync-active = <0>` -> `href_pol: 1`
was found by `printk()`-like debugging.

(This can be not relevant or incorrect) What was found also is that
active high horizontal wire (whatever it is called in datasheet, PCB,
dts or driver) from e.g. FPGA corresponds to `href_pol: 1` to
correctly read image lines sent.

Thanks!
-- 
sed 'sh && sed && node.js + olecom = happiness and mirth'  <<  ''
-o--=O`C
 #oo'L O
<___=E M