Hi Maxime,

On Wed, Aug 17, 2022 at 3:15 PM Maxime Ripard [off-list ref] wrote:

On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote:

quoted

On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard [off-list ref] wrote:

quoted

On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:

quoted

On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard [off-list ref] wrote:

quoted

On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:

quoted

On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard [off-list ref] wrote:

quoted

Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
modes in the drivers.

Nit: strictly speaking these are not analog modes, but the digital
variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
13.5 MHz sampling frequency for pixels.

In analog modes, the only discrete values are the number of lines, and
the frame/field rate (fixing the horizontal sync rate when combined).

The number of (in)visible pixels per line depends on the available
bandwidth.  In a digital variant (which is anything generated by a
digital computer system), the latter depends on the pixel clock, which
can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).

So I think we probably need some way to generate a PAL/NTSC-compatible
mode based not only on resolution, but also on pixel clock.

This would also fix the comments made by Jani and Thomas, so I quite
like the idea of it.

I'm struggling a bit to find how would could implement this though.

From what you were saying, I guess the prototype would be something like

struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
                                                unsigned int lines,
                                                unsigned int frame_rate)

But I have zero idea on what the implementation would be. Do you have
some resources for this you could point me to?

Horizontally, I think you should calculate left/right margins and
hsync length to yield timings that match those for the BT.656 PAL/NTSC
modes.  I.e. when a 640x512 mode with a pixel clock of 14 MHz is
requested, you want to calculate left', right', and hslen' for

| <---- left' ---> | <- 640 pixels -> | <---- right' ---> | <--- hslen' --> |
                        @ 14 MHz

so they match the timings for left, right, and hslen for

| <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
                        @ 13.5 MHz

As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
you want to make sure to align the center of the visible part.

So I guess in that example if we want to center it, left == right and
left' == right'? What about the sync length?

No, left and right are asymmetrical, cfr. front and back porch in
https://en.wikipedia.org/wiki/PAL#PAL_signal_details
I.e. if the pixel part is reduced, both the left and right margins
should be increased by the same amount.

From the table linked above, hslen should be ca. 4.7µs (fixed).

each pixel taking 1 / pixel_clock seconds (assuming pixel_clock is in
Hz), and thus hslen (in pixels) = 4.7 * 10 ^ -6 * pixel_clk, right?

Exactly.

quoted

quoted

quoted

Vertically, it's simpler, as the number of lines is discrete.
You do have to take into account interlace and doublescan, and
progressive modes with 262/312 lines.

So we only have to deal with 525 and 625 lines total (without taking
interlace and doublescan into account), right?

Yes.

quoted

I guess we still have the same question, we probably want to center it,
so top == bottom, but what about the vsync length?

Unfortunately that table does not mention top and bottom margins.
But according to drivers/video/fbdev/amifb.c (see the "Broadcast
video timings" comment block and the definitions of the "ntsc-lace"
and "pal-lace" video modes), they are asymmetrical, too.

Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't
have that info when I wrote amifb, as I used 4 lines there).

Thanks, that's some great info already.

It's mentioned though that the settings for NTSC are "straightforward",
but it's definitely not for me :)

As in NTSC just uses different pixel clock and horizontal/vertical sync
rate values...

I've looked around and it looks like the entire blanking area is
supposed to be 40 pixels in interlaced, but I couldn't find anywhere how

625 lines - 575[*] visible lines = 50 lines.

[*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
     a frame in two fields of equal size.

"visible" is relative, as it includes the overscan region.
Some PAL monitors used with computers had knobs to control width/height
and position of the screen, so you could make use of most or all of
the overscan region, but on a real TV you're limited to ca. 640x512 (on
PAL)  which is what an Amiga used by default (with a 14 MHz pixclock).

it's supposed to be split between the upper and lower margins and the
sync period.

"Field Synchronization of PAL System" on http://martin.hinner.info/vga/pal.html
shows the split.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel