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

Hi,

On Fri, Sep 23, 2022 at 11:05:48AM +0200, Thomas Zimmermann wrote:
> > +	/* 63.556us * 13.5MHz = 858 pixels */
> 
> I kind of get what the comment wants to tell me, but the units don't add up.

I'm not sure how it doesn't add up?

We have a frequency in Hz (equivalent to s^-1) and a duration in s, so
the result ends up with no dimension, which is to be expected for a
number of periods?

If you're talking about the comment itself, then NTSC mandates that a
line is 63.556us long. If we're using a pixel clock at 13.5 MHz, it
means that the period (== pixel) is ~74ns, so we get 63556 / 74 = 858
pixels / line.

> I think you want to end up with 858 pixels/line =
> 
>   13,5 pixels/second / (60/2I frame/second * 525 lines/frame)
> 
> I: interlaced
> 
> Maybe just remove the short comments and document that in a more meaningful
> place.

I guess this is where it's meaningful, we really want to hit that
target. BT601 also mandates it.

Maxime

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