linux-kernel - Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes

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]

Date:   Wed, 21 Sep 2022 16:26:32 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     kFYatek <kfyatek@...il.com>
Cc:     Ben Skeggs <bskeggs@...hat.com>, David Airlie <airlied@...ux.ie>,
        Chen-Yu Tsai <wens@...e.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Lyude Paul <lyude@...hat.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Karol Herbst <kherbst@...hat.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Emma Anholt <emma@...olt.net>, Daniel Vetter <daniel@...ll.ch>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>,
        linux-arm-kernel@...ts.infradead.org,
        Phil Elwell <phil@...pberrypi.com>,
        intel-gfx@...ts.freedesktop.org,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        dri-devel@...ts.freedesktop.org, Dom Cobley <dom@...pberrypi.com>,
        linux-kernel@...r.kernel.org, nouveau@...ts.freedesktop.org,
        linux-sunxi@...ts.linux.dev,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog
 display modes

Hi,

Thanks again for your help

On Sun, Sep 11, 2022 at 06:30:39AM +0200, kFYatek wrote:
> W dniu 9.09.2022 o 16:00, Maxime Ripard pisze:
> > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> >> The "canonical" modelines (at least for vc4's VEC, see the notes below):
> >>
> >> - (vfp==4, vsync==6, vbp==39) for 576i
> >> - (vfp==7, vsync==6, vbp==32) for 480i
> >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally specified)
> >
> > It's not clear to me either how you come up with those timings?
> 
> Well, experimentally ;)
> 
> The values for 480i and 576i are the values currently used by the downstream
> kernel, and those in turn has been copied from the firmware (or more precisely,
> I chose them so that the PV registers end up the same as the values set by the
> firmware).
> 
> I also checked with an oscilloscope that the waveforms look as they should.
> VEC doesn't exactly handle the half-lines at the start and end of the odd field
> right, but otherwise, the blanking and sync pulses are where they should be.
> 
> The 486i values has been constructed from the 480i ones according to the
> calculations from cross-referencing SMPTE documents, see my previous e-mail.
> 
> I know this is perhaps unsatisfactory ;) I don't have access to the VC4
> documentation, so this was _almost_ reverse engineering for me.

It's not really that it's unsatisfactory, but the function here is
supposed to be generic and thus generate a mode that is supposed to be a
somewhat reasonable for a given set of parameters.

If the vc4 driver needs some adjustments, then it needs to be out of
that function and into the vc4 driver. And this is pretty much what I
struggle with: I have a hard time (on top of everything else) figuring
out what is supposed to be specific to vc4, and what isn't.

I guess your 480i example, since it follows the spec, is fine, but I'm
not sure for 576i.
Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)