All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-sunxi@lists.linux.dev,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Mateusz Kwiatkowski" <kfyatek+publicgit@gmail.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Dom Cobley" <dom@raspberrypi.com>
Subject: Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Date: Thu, 18 Aug 2022 15:42:00 +0200	[thread overview]
Message-ID: <20220818134200.cr22bftmjn226ehn@houat> (raw)
In-Reply-To: <CAMuHMdWXbHkrBZgsmUnU=q52+q7UZZNO3tgQW7Men+msQ1JDwQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]

On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > 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
> >
> > It brings back some memories :)
> >
> > > 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.
> >
> > Thanks, that's excellent as well.
> >
> > I'm mostly done with a function that creates a PAL mode, but I still
> > have one question.
> >
> > If I understand well, the blanking period is made up (interlace) of 16
> > pulses for the first field, 14 for the second, each pulse taking half a
> > line. That amount to 30 pulses, so 15 lines.
> >
> > I first assumed that the pre-equalizing pulses would be the back porch,
> > the long sync pulses the vsync, and the post-equalizing pulses the front
> > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> >
> > So I guess my assumption was wrong to begin with.
> 
> The back porch is the number of lines between the last "visible" line
> and the start of the synchronization pulse, i.e. "l" in the "Field
> Synchronization of PAL System" drawing.
> Virtual sync length is "m".
> The front porch is the number of lines between the end of
> the synchronization pulse, and the first "visible" line, i.e.
> "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).

Ah, yes, that makes sense

> > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> 
> Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> so "4" is not that much off of 2.5 + 3.

Is it? If I'm reading that drawing well, l before the first field starts
on the second half of line 623 and stops at the end of line 625, so 2.5
line, and on the second field starts at the beginning of line 311, and
stops half-way through 313 so 2.5 line again.

Then, for the first field, m starts at the beginning of line 1, stops
half-way through line 3, so 2.5 line indeed, and then on the second
field starts on the second half of 313 and stops at the end of line 315.
So 2.5 again?

Thus, both should be 5?

> > understand how you come up with the upper and lower margins (or rather,
> > how they are linked to what's described in that page)
> 
> These margins probably came from the Amiga hardware reference manual,
> for the default 640x512 (PAL) and 640x400 (NTSC) modes.

Ok.

I started adding more sanity checks to my code, and I just realised I
don't seem to be able to reach 720 pixels over a single line though. If
I understood it properly, and according to [1] the active part of a line
is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
in the timing section has pretty much the same numbers, so it looks
sane.

At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
pixels

It seems we can go push it to 52350 ns, but that still gives us only 706
pixels.

Similarly, if I just choose to ignore that limit and just take the
active time I need, 720 * 74 = 53280ns

That leaves us 10720ns for the blanking period, and that's not enough to
fit even the minimum of the front porch, hsync and back porch (1.55 +
4.5 + 5.5 = 11.55us).

Are those constraints merely recommendations, or am I missing something?

Thanks!
Maxime

1: https://en.wikipedia.org/wiki/PAL#PAL_signal_details
2: http://martin.hinner.info/vga/pal.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Emma Anholt" <emma@anholt.net>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"David Airlie" <airlied@linux.ie>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	linux-sunxi@lists.linux.dev,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Dom Cobley" <dom@raspberrypi.com>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Mateusz Kwiatkowski" <kfyatek+publicgit@gmail.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Date: Thu, 18 Aug 2022 15:42:00 +0200	[thread overview]
Message-ID: <20220818134200.cr22bftmjn226ehn@houat> (raw)
In-Reply-To: <CAMuHMdWXbHkrBZgsmUnU=q52+q7UZZNO3tgQW7Men+msQ1JDwQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]

On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > 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
> >
> > It brings back some memories :)
> >
> > > 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.
> >
> > Thanks, that's excellent as well.
> >
> > I'm mostly done with a function that creates a PAL mode, but I still
> > have one question.
> >
> > If I understand well, the blanking period is made up (interlace) of 16
> > pulses for the first field, 14 for the second, each pulse taking half a
> > line. That amount to 30 pulses, so 15 lines.
> >
> > I first assumed that the pre-equalizing pulses would be the back porch,
> > the long sync pulses the vsync, and the post-equalizing pulses the front
> > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> >
> > So I guess my assumption was wrong to begin with.
> 
> The back porch is the number of lines between the last "visible" line
> and the start of the synchronization pulse, i.e. "l" in the "Field
> Synchronization of PAL System" drawing.
> Virtual sync length is "m".
> The front porch is the number of lines between the end of
> the synchronization pulse, and the first "visible" line, i.e.
> "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).

Ah, yes, that makes sense

> > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> 
> Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> so "4" is not that much off of 2.5 + 3.

Is it? If I'm reading that drawing well, l before the first field starts
on the second half of line 623 and stops at the end of line 625, so 2.5
line, and on the second field starts at the beginning of line 311, and
stops half-way through 313 so 2.5 line again.

Then, for the first field, m starts at the beginning of line 1, stops
half-way through line 3, so 2.5 line indeed, and then on the second
field starts on the second half of 313 and stops at the end of line 315.
So 2.5 again?

Thus, both should be 5?

> > understand how you come up with the upper and lower margins (or rather,
> > how they are linked to what's described in that page)
> 
> These margins probably came from the Amiga hardware reference manual,
> for the default 640x512 (PAL) and 640x400 (NTSC) modes.

Ok.

I started adding more sanity checks to my code, and I just realised I
don't seem to be able to reach 720 pixels over a single line though. If
I understood it properly, and according to [1] the active part of a line
is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
in the timing section has pretty much the same numbers, so it looks
sane.

At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
pixels

It seems we can go push it to 52350 ns, but that still gives us only 706
pixels.

Similarly, if I just choose to ignore that limit and just take the
active time I need, 720 * 74 = 53280ns

That leaves us 10720ns for the blanking period, and that's not enough to
fit even the minimum of the front porch, hsync and back porch (1.55 +
4.5 + 5.5 = 11.55us).

Are those constraints merely recommendations, or am I missing something?

Thanks!
Maxime

1: https://en.wikipedia.org/wiki/PAL#PAL_signal_details
2: http://martin.hinner.info/vga/pal.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-sunxi@lists.linux.dev,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Mateusz Kwiatkowski" <kfyatek+publicgit@gmail.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Dom Cobley" <dom@raspberrypi.com>
Subject: Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Date: Thu, 18 Aug 2022 15:42:00 +0200	[thread overview]
Message-ID: <20220818134200.cr22bftmjn226ehn@houat> (raw)
In-Reply-To: <CAMuHMdWXbHkrBZgsmUnU=q52+q7UZZNO3tgQW7Men+msQ1JDwQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4453 bytes --]

On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > 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
> >
> > It brings back some memories :)
> >
> > > 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.
> >
> > Thanks, that's excellent as well.
> >
> > I'm mostly done with a function that creates a PAL mode, but I still
> > have one question.
> >
> > If I understand well, the blanking period is made up (interlace) of 16
> > pulses for the first field, 14 for the second, each pulse taking half a
> > line. That amount to 30 pulses, so 15 lines.
> >
> > I first assumed that the pre-equalizing pulses would be the back porch,
> > the long sync pulses the vsync, and the post-equalizing pulses the front
> > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> >
> > So I guess my assumption was wrong to begin with.
> 
> The back porch is the number of lines between the last "visible" line
> and the start of the synchronization pulse, i.e. "l" in the "Field
> Synchronization of PAL System" drawing.
> Virtual sync length is "m".
> The front porch is the number of lines between the end of
> the synchronization pulse, and the first "visible" line, i.e.
> "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).

Ah, yes, that makes sense

> > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> 
> Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> so "4" is not that much off of 2.5 + 3.

Is it? If I'm reading that drawing well, l before the first field starts
on the second half of line 623 and stops at the end of line 625, so 2.5
line, and on the second field starts at the beginning of line 311, and
stops half-way through 313 so 2.5 line again.

Then, for the first field, m starts at the beginning of line 1, stops
half-way through line 3, so 2.5 line indeed, and then on the second
field starts on the second half of 313 and stops at the end of line 315.
So 2.5 again?

Thus, both should be 5?

> > understand how you come up with the upper and lower margins (or rather,
> > how they are linked to what's described in that page)
> 
> These margins probably came from the Amiga hardware reference manual,
> for the default 640x512 (PAL) and 640x400 (NTSC) modes.

Ok.

I started adding more sanity checks to my code, and I just realised I
don't seem to be able to reach 720 pixels over a single line though. If
I understood it properly, and according to [1] the active part of a line
is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
in the timing section has pretty much the same numbers, so it looks
sane.

At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
pixels

It seems we can go push it to 52350 ns, but that still gives us only 706
pixels.

Similarly, if I just choose to ignore that limit and just take the
active time I need, 720 * 74 = 53280ns

That leaves us 10720ns for the blanking period, and that's not enough to
fit even the minimum of the front porch, hsync and back porch (1.55 +
4.5 + 5.5 = 11.55us).

Are those constraints merely recommendations, or am I missing something?

Thanks!
Maxime

1: https://en.wikipedia.org/wiki/PAL#PAL_signal_details
2: http://martin.hinner.info/vga/pal.html

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

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

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-sunxi@lists.linux.dev,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Mateusz Kwiatkowski" <kfyatek+publicgit@gmail.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Dom Cobley" <dom@raspberrypi.com>
Subject: Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Date: Thu, 18 Aug 2022 15:42:00 +0200	[thread overview]
Message-ID: <20220818134200.cr22bftmjn226ehn@houat> (raw)
In-Reply-To: <CAMuHMdWXbHkrBZgsmUnU=q52+q7UZZNO3tgQW7Men+msQ1JDwQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4453 bytes --]

On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > 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
> >
> > It brings back some memories :)
> >
> > > 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.
> >
> > Thanks, that's excellent as well.
> >
> > I'm mostly done with a function that creates a PAL mode, but I still
> > have one question.
> >
> > If I understand well, the blanking period is made up (interlace) of 16
> > pulses for the first field, 14 for the second, each pulse taking half a
> > line. That amount to 30 pulses, so 15 lines.
> >
> > I first assumed that the pre-equalizing pulses would be the back porch,
> > the long sync pulses the vsync, and the post-equalizing pulses the front
> > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> >
> > So I guess my assumption was wrong to begin with.
> 
> The back porch is the number of lines between the last "visible" line
> and the start of the synchronization pulse, i.e. "l" in the "Field
> Synchronization of PAL System" drawing.
> Virtual sync length is "m".
> The front porch is the number of lines between the end of
> the synchronization pulse, and the first "visible" line, i.e.
> "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).

Ah, yes, that makes sense

> > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> 
> Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> so "4" is not that much off of 2.5 + 3.

Is it? If I'm reading that drawing well, l before the first field starts
on the second half of line 623 and stops at the end of line 625, so 2.5
line, and on the second field starts at the beginning of line 311, and
stops half-way through 313 so 2.5 line again.

Then, for the first field, m starts at the beginning of line 1, stops
half-way through line 3, so 2.5 line indeed, and then on the second
field starts on the second half of 313 and stops at the end of line 315.
So 2.5 again?

Thus, both should be 5?

> > understand how you come up with the upper and lower margins (or rather,
> > how they are linked to what's described in that page)
> 
> These margins probably came from the Amiga hardware reference manual,
> for the default 640x512 (PAL) and 640x400 (NTSC) modes.

Ok.

I started adding more sanity checks to my code, and I just realised I
don't seem to be able to reach 720 pixels over a single line though. If
I understood it properly, and according to [1] the active part of a line
is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
in the timing section has pretty much the same numbers, so it looks
sane.

At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
pixels

It seems we can go push it to 52350 ns, but that still gives us only 706
pixels.

Similarly, if I just choose to ignore that limit and just take the
active time I need, 720 * 74 = 53280ns

That leaves us 10720ns for the blanking period, and that's not enough to
fit even the minimum of the front porch, hsync and back porch (1.55 +
4.5 + 5.5 = 11.55us).

Are those constraints merely recommendations, or am I missing something?

Thanks!
Maxime

1: https://en.wikipedia.org/wiki/PAL#PAL_signal_details
2: http://martin.hinner.info/vga/pal.html

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

  reply	other threads:[~2022-08-18 13:42 UTC|newest]

Thread overview: 604+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 16:34 [PATCH v1 00/35] drm: Analog TV Improvements Maxime Ripard
2022-07-29 16:34 ` Maxime Ripard
2022-07-29 16:34 ` Maxime Ripard
2022-07-29 16:34 ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 01/35] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-08 12:25   ` Noralf Trønnes
2022-08-08 12:25     ` Noralf Trønnes
2022-08-08 12:25     ` Noralf Trønnes
2022-08-08 12:25     ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 02/35] drm/connector: Rename subconnector state variable Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-08 12:26   ` Noralf Trønnes
2022-08-08 12:26     ` Noralf Trønnes
2022-08-08 12:26     ` Noralf Trønnes
2022-08-08 12:26     ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 03/35] drm/atomic: Add TV subconnector property to get/set_property Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-08 12:30   ` Noralf Trønnes
2022-08-08 12:30     ` Noralf Trønnes
2022-08-08 12:30     ` Noralf Trønnes
2022-08-08 12:30     ` Noralf Trønnes
2022-08-15  7:35     ` Maxime Ripard
2022-08-15  7:35       ` Maxime Ripard
2022-08-15  7:35       ` Maxime Ripard
2022-08-15  7:35       ` Maxime Ripard
2022-08-15 10:48       ` Noralf Trønnes
2022-08-15 10:48         ` Noralf Trønnes
2022-08-15 10:48         ` Noralf Trønnes
2022-08-15 10:48         ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-02 13:58   ` Jani Nikula
2022-08-02 13:58     ` Jani Nikula
2022-08-02 13:58     ` Jani Nikula
2022-08-02 13:58     ` Jani Nikula
2022-08-02 14:16     ` Thomas Zimmermann
2022-08-02 14:16       ` Thomas Zimmermann
2022-08-02 14:16       ` Thomas Zimmermann
2022-08-02 14:16       ` Thomas Zimmermann
2022-08-16 11:58       ` Maxime Ripard
2022-08-16 11:58         ` Maxime Ripard
2022-08-16 11:58         ` Maxime Ripard
2022-08-16 11:58         ` Maxime Ripard
2022-08-12 13:18   ` Geert Uytterhoeven
2022-08-12 13:18     ` Geert Uytterhoeven
2022-08-12 13:18     ` Geert Uytterhoeven
2022-08-12 13:18     ` Geert Uytterhoeven
2022-08-16 13:26     ` Maxime Ripard
2022-08-16 13:26       ` Maxime Ripard
2022-08-16 13:26       ` Maxime Ripard
2022-08-16 13:26       ` Maxime Ripard
2022-08-16 15:00       ` Geert Uytterhoeven
2022-08-16 15:00         ` Geert Uytterhoeven
2022-08-16 15:00         ` Geert Uytterhoeven
2022-08-16 15:00         ` Geert Uytterhoeven
2022-08-17  7:53         ` Maxime Ripard
2022-08-17  7:53           ` Maxime Ripard
2022-08-17  7:53           ` Maxime Ripard
2022-08-17  7:53           ` Maxime Ripard
2022-08-17  8:51           ` Geert Uytterhoeven
2022-08-17  8:51             ` Geert Uytterhoeven
2022-08-17  8:51             ` Geert Uytterhoeven
2022-08-17  8:51             ` Geert Uytterhoeven
2022-08-17 13:14             ` Maxime Ripard
2022-08-17 13:14               ` Maxime Ripard
2022-08-17 13:14               ` Maxime Ripard
2022-08-17 13:14               ` Maxime Ripard
2022-08-17 14:01               ` Geert Uytterhoeven
2022-08-17 14:01                 ` Geert Uytterhoeven
2022-08-17 14:01                 ` Geert Uytterhoeven
2022-08-17 14:01                 ` Geert Uytterhoeven
2022-08-18 12:39                 ` Maxime Ripard
2022-08-18 12:39                   ` Maxime Ripard
2022-08-18 12:39                   ` Maxime Ripard
2022-08-18 12:39                   ` Maxime Ripard
2022-08-18 12:57                   ` Geert Uytterhoeven
2022-08-18 12:57                     ` Geert Uytterhoeven
2022-08-18 12:57                     ` Geert Uytterhoeven
2022-08-18 12:57                     ` Geert Uytterhoeven
2022-08-18 13:42                     ` Maxime Ripard [this message]
2022-08-18 13:42                       ` Maxime Ripard
2022-08-18 13:42                       ` Maxime Ripard
2022-08-18 13:42                       ` Maxime Ripard
2022-08-18 15:34                       ` Geert Uytterhoeven
2022-08-18 15:34                         ` Geert Uytterhoeven
2022-08-18 15:34                         ` Geert Uytterhoeven
2022-08-18 15:34                         ` Geert Uytterhoeven
2022-08-18 15:46                         ` Maxime Ripard
2022-08-18 15:46                           ` Maxime Ripard
2022-08-18 15:46                           ` Maxime Ripard
2022-08-18 15:46                           ` Maxime Ripard
2022-08-18 15:56                           ` Geert Uytterhoeven
2022-08-18 15:56                             ` Geert Uytterhoeven
2022-08-18 15:56                             ` Geert Uytterhoeven
2022-08-18 15:56                             ` Geert Uytterhoeven
2022-08-24 16:42                             ` Mateusz Kwiatkowski
2022-08-24 16:42                               ` Mateusz Kwiatkowski
2022-08-24 16:42                               ` Mateusz Kwiatkowski
2022-08-24 16:42                               ` Mateusz Kwiatkowski
2022-08-29 13:29                               ` Maxime Ripard
2022-08-29 13:29                                 ` Maxime Ripard
2022-08-29 13:29                                 ` Maxime Ripard
2022-08-29 13:29                                 ` Maxime Ripard
2022-08-29 14:14                                 ` Geert Uytterhoeven
2022-08-29 14:14                                   ` Geert Uytterhoeven
2022-08-29 14:14                                   ` Geert Uytterhoeven
2022-08-29 14:14                                   ` Geert Uytterhoeven
2022-08-29 14:33                                   ` Maxime Ripard
2022-08-29 14:33                                     ` Maxime Ripard
2022-08-29 14:33                                     ` Maxime Ripard
2022-08-29 14:33                                     ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 05/35] drm/connector: Add TV standard property Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-08 12:44   ` Noralf Trønnes
2022-08-08 12:44     ` Noralf Trønnes
2022-08-08 12:44     ` Noralf Trønnes
2022-08-08 12:44     ` Noralf Trønnes
2022-08-16  8:26     ` Maxime Ripard
2022-08-16  8:26       ` Maxime Ripard
2022-08-16  8:26       ` Maxime Ripard
2022-08-16  8:26       ` Maxime Ripard
2022-08-16  9:42       ` Noralf Trønnes
2022-08-16  9:42         ` Noralf Trønnes
2022-08-16  9:42         ` Noralf Trønnes
2022-08-16  9:42         ` Noralf Trønnes
2022-08-16  9:49         ` Maxime Ripard
2022-08-16  9:49           ` Maxime Ripard
2022-08-16  9:49           ` Maxime Ripard
2022-08-16  9:49           ` Maxime Ripard
2022-08-16 19:35           ` Noralf Trønnes
2022-08-16 19:35             ` Noralf Trønnes
2022-08-16 19:35             ` Noralf Trønnes
2022-08-16 19:35             ` Noralf Trønnes
2022-08-17 11:46             ` Maxime Ripard
2022-08-17 11:46               ` Maxime Ripard
2022-08-17 11:46               ` Maxime Ripard
2022-08-17 11:46               ` Maxime Ripard
2022-08-17 13:11               ` Noralf Trønnes
2022-08-17 13:11                 ` Noralf Trønnes
2022-08-17 13:11                 ` Noralf Trønnes
2022-08-17 13:11                 ` Noralf Trønnes
2022-08-17 23:23                 ` Noralf Trønnes
2022-08-17 23:23                   ` Noralf Trønnes
2022-08-17 23:23                   ` Noralf Trønnes
2022-08-17 23:23                   ` Noralf Trønnes
2022-08-18 15:01                   ` Noralf Trønnes
2022-08-18 15:01                     ` Noralf Trønnes
2022-08-18 15:01                     ` Noralf Trønnes
2022-08-18 15:01                     ` Noralf Trønnes
2022-08-18 15:31                     ` Maxime Ripard
2022-08-18 15:31                       ` Maxime Ripard
2022-08-18 15:31                       ` Maxime Ripard
2022-08-18 15:31                       ` Maxime Ripard
2022-08-21 11:43                       ` Noralf Trønnes
2022-08-21 11:43                         ` Noralf Trønnes
2022-08-21 11:43                         ` Noralf Trønnes
2022-08-21 11:43                         ` Noralf Trønnes
2022-08-26  8:21                         ` Maxime Ripard
2022-08-26  8:21                           ` Maxime Ripard
2022-08-26  8:21                           ` Maxime Ripard
2022-08-26  8:21                           ` Maxime Ripard
2022-08-18 15:27                 ` Maxime Ripard
2022-08-18 15:27                   ` Maxime Ripard
2022-08-18 15:27                   ` Maxime Ripard
2022-08-18 15:27                   ` Maxime Ripard
2022-08-12 13:25   ` Geert Uytterhoeven
2022-08-12 13:25     ` Geert Uytterhoeven
2022-08-12 13:25     ` Geert Uytterhoeven
2022-08-12 13:25     ` Geert Uytterhoeven
2022-08-16 13:20     ` Maxime Ripard
2022-08-16 13:20       ` Maxime Ripard
2022-08-16 13:20       ` Maxime Ripard
2022-08-16 13:20       ` Maxime Ripard
2022-08-16 13:29       ` Geert Uytterhoeven
2022-08-16 13:29         ` Geert Uytterhoeven
2022-08-16 13:29         ` Geert Uytterhoeven
2022-08-16 13:29         ` Geert Uytterhoeven
2022-08-16 14:11         ` Maxime Ripard
2022-08-16 14:11           ` Maxime Ripard
2022-08-16 14:11           ` Maxime Ripard
2022-08-16 14:11           ` Maxime Ripard
2022-08-16 14:43           ` Geert Uytterhoeven
2022-08-16 14:43             ` Geert Uytterhoeven
2022-08-16 14:43             ` Geert Uytterhoeven
2022-08-16 14:43             ` Geert Uytterhoeven
2022-08-16 15:49             ` Maxime Ripard
2022-08-16 15:49               ` Maxime Ripard
2022-08-16 15:49               ` Maxime Ripard
2022-08-16 15:49               ` Maxime Ripard
2022-08-17  7:31               ` Geert Uytterhoeven
2022-08-17  7:31                 ` Geert Uytterhoeven
2022-08-17  7:31                 ` Geert Uytterhoeven
2022-08-17  7:31                 ` Geert Uytterhoeven
2022-08-17  7:32                 ` Geert Uytterhoeven
2022-08-17  7:32                   ` Geert Uytterhoeven
2022-08-17  7:32                   ` Geert Uytterhoeven
2022-08-17  7:32                   ` Geert Uytterhoeven
2022-08-17  7:47                 ` Maxime Ripard
2022-08-17  7:47                   ` Maxime Ripard
2022-08-17  7:47                   ` Maxime Ripard
2022-08-17  7:47                   ` Maxime Ripard
2022-08-17  8:35                   ` Geert Uytterhoeven
2022-08-17  8:35                     ` Geert Uytterhoeven
2022-08-17  8:35                     ` Geert Uytterhoeven
2022-08-17  8:35                     ` Geert Uytterhoeven
2022-08-17 11:14                     ` Maxime Ripard
2022-08-17 11:14                       ` Maxime Ripard
2022-08-17 11:14                       ` Maxime Ripard
2022-08-17 11:14                       ` Maxime Ripard
2022-08-17 13:05                       ` Geert Uytterhoeven
2022-08-17 13:05                         ` Geert Uytterhoeven
2022-08-17 13:05                         ` Geert Uytterhoeven
2022-08-17 13:05                         ` Geert Uytterhoeven
2022-08-17 13:18                         ` Maxime Ripard
2022-08-17 13:18                           ` Maxime Ripard
2022-08-17 13:18                           ` Maxime Ripard
2022-08-17 13:18                           ` Maxime Ripard
2022-08-17 14:04                           ` Geert Uytterhoeven
2022-08-17 14:04                             ` Geert Uytterhoeven
2022-08-17 14:04                             ` Geert Uytterhoeven
2022-08-17 14:04                             ` Geert Uytterhoeven
2022-08-18 14:54                             ` Maxime Ripard
2022-08-18 14:54                               ` Maxime Ripard
2022-08-18 14:54                               ` Maxime Ripard
2022-08-18 14:54                               ` Maxime Ripard
2022-08-18 15:20                               ` Geert Uytterhoeven
2022-08-18 15:20                                 ` Geert Uytterhoeven
2022-08-18 15:20                                 ` Geert Uytterhoeven
2022-08-18 15:20                                 ` Geert Uytterhoeven
2022-08-18 15:34                                 ` Maxime Ripard
2022-08-18 15:34                                   ` Maxime Ripard
2022-08-18 15:34                                   ` Maxime Ripard
2022-08-18 15:34                                   ` Maxime Ripard
2022-08-19  9:35                                   ` Geert Uytterhoeven
2022-08-19  9:35                                     ` Geert Uytterhoeven
2022-08-19  9:35                                     ` Geert Uytterhoeven
2022-08-19  9:35                                     ` Geert Uytterhoeven
2022-08-25 13:39                                     ` Maxime Ripard
2022-08-25 13:39                                       ` Maxime Ripard
2022-08-25 13:39                                       ` Maxime Ripard
2022-08-25 13:39                                       ` Maxime Ripard
2022-08-20 20:12   ` Noralf Trønnes
2022-08-20 20:12     ` Noralf Trønnes
2022-08-20 20:12     ` Noralf Trønnes
2022-08-20 20:12     ` Noralf Trønnes
2022-08-25 13:44     ` Maxime Ripard
2022-08-25 13:44       ` Maxime Ripard
2022-08-25 13:44       ` Maxime Ripard
2022-08-25 13:44       ` Maxime Ripard
2022-08-25 15:13       ` Noralf Trønnes
2022-08-25 15:13         ` Noralf Trønnes
2022-08-25 15:13         ` Noralf Trønnes
2022-08-25 15:13         ` Noralf Trønnes
2022-08-29  8:28         ` Maxime Ripard
2022-08-29  8:28           ` Maxime Ripard
2022-08-29  8:28           ` Maxime Ripard
2022-08-29  8:28           ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 06/35] drm/connector: Only register TV mode property if present Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-08 12:49   ` Noralf Trønnes
2022-08-08 12:49     ` Noralf Trønnes
2022-08-08 12:49     ` Noralf Trønnes
2022-08-08 12:49     ` Noralf Trønnes
2022-08-15 10:40     ` Maxime Ripard
2022-08-15 10:40       ` Maxime Ripard
2022-08-15 10:40       ` Maxime Ripard
2022-08-15 10:40       ` Maxime Ripard
2022-08-15 10:49       ` Noralf Trønnes
2022-08-15 10:49         ` Noralf Trønnes
2022-08-15 10:49         ` Noralf Trønnes
2022-08-15 10:49         ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 07/35] drm/modes: Only consider bpp and refresh before options Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-12 13:25   ` Geert Uytterhoeven
2022-08-12 13:25     ` Geert Uytterhoeven
2022-08-12 13:25     ` Geert Uytterhoeven
2022-08-12 13:25     ` Geert Uytterhoeven
2022-08-16 12:20     ` Maxime Ripard
2022-08-16 12:20       ` Maxime Ripard
2022-08-16 12:20       ` Maxime Ripard
2022-08-16 12:20       ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 08/35] drm/client: Add some tests for drm_connector_pick_cmdline_mode() Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-02 10:14   ` Thomas Zimmermann
2022-08-02 10:14     ` Thomas Zimmermann
2022-08-02 10:14     ` Thomas Zimmermann
2022-08-02 10:14     ` Thomas Zimmermann
2022-08-15  8:42     ` Maxime Ripard
2022-08-15  8:42       ` Maxime Ripard
2022-08-15  8:42       ` Maxime Ripard
2022-08-15  8:42       ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-08-12 13:27   ` Geert Uytterhoeven
2022-08-12 13:27     ` Geert Uytterhoeven
2022-08-12 13:27     ` Geert Uytterhoeven
2022-08-12 13:27     ` Geert Uytterhoeven
2022-08-16 13:46     ` Maxime Ripard
2022-08-16 13:46       ` Maxime Ripard
2022-08-16 13:46       ` Maxime Ripard
2022-08-16 13:46       ` Maxime Ripard
2022-08-16 14:44       ` Geert Uytterhoeven
2022-08-16 14:44         ` Geert Uytterhoeven
2022-08-16 14:44         ` Geert Uytterhoeven
2022-08-16 14:44         ` Geert Uytterhoeven
2022-07-29 16:34 ` [PATCH v1 10/35] drm/modes: Switch to named mode descriptors Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 11/35] drm/modes: Fill drm_cmdline mode from named modes Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 12/35] drmi/modes: Properly generate a drm_display_mode from a named mode Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 13/35] drm/atomic-helper: Add a TV properties reset helper Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 14/35] drm/atomic-helper: Add an analog TV atomic_check implementation Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 17:16   ` Mateusz Kwiatkowski
2022-07-29 17:16     ` Mateusz Kwiatkowski
2022-07-29 17:16     ` Mateusz Kwiatkowski
2022-07-29 17:16     ` Mateusz Kwiatkowski
2022-08-15  8:30     ` Maxime Ripard
2022-08-15  8:30       ` Maxime Ripard
2022-08-15  8:30       ` Maxime Ripard
2022-08-15  8:30       ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 15/35] drm/vc4: vec: Remove empty mode_fixup Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 16/35] drm/vc4: vec: Convert to atomic helpers Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:34   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 17/35] drm/vc4: vec: Refactor VEC TV mode setting Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 18/35] drm/vc4: vec: Remove redundant atomic_mode_set Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 19/35] drm/vc4: vec: Fix timings for VEC modes Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 20/35] drm/vc4: vec: Switch for common modes Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 18:12   ` Mateusz Kwiatkowski
2022-07-29 18:12     ` Mateusz Kwiatkowski
2022-07-29 18:12     ` Mateusz Kwiatkowski
2022-07-29 18:12     ` Mateusz Kwiatkowski
2022-08-16 11:57     ` Maxime Ripard
2022-08-16 11:57       ` Maxime Ripard
2022-08-16 11:57       ` Maxime Ripard
2022-08-16 11:57       ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 21/35] drm/vc4: vec: Fix definition of PAL-M mode Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 22/35] drm/vc4: vec: Use TV Reset implementation Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-30  3:03   ` kernel test robot
2022-07-30  3:03     ` kernel test robot
2022-07-30  3:03     ` kernel test robot
2022-07-30  3:03     ` kernel test robot
2022-07-29 16:35 ` [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-08-20 17:22   ` Noralf Trønnes
2022-08-20 17:22     ` Noralf Trønnes
2022-08-20 17:22     ` Noralf Trønnes
2022-08-20 17:22     ` Noralf Trønnes
2022-08-24 15:26     ` Maxime Ripard
2022-08-24 15:26       ` Maxime Ripard
2022-08-24 15:26       ` Maxime Ripard
2022-08-24 15:26       ` Maxime Ripard
2022-08-25 13:14       ` Noralf Trønnes
2022-08-25 13:14         ` Noralf Trønnes
2022-08-25 13:14         ` Noralf Trønnes
2022-08-25 13:14         ` Noralf Trønnes
2022-08-29 12:13         ` Maxime Ripard
2022-08-29 12:13           ` Maxime Ripard
2022-08-29 12:13           ` Maxime Ripard
2022-08-29 12:13           ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 24/35] drm/vc4: vec: Add support for more analog TV standards Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 17:55   ` Mateusz Kwiatkowski
2022-07-29 17:55     ` Mateusz Kwiatkowski
2022-07-29 17:55     ` Mateusz Kwiatkowski
2022-07-29 17:55     ` Mateusz Kwiatkowski
2022-08-15  8:37     ` Maxime Ripard
2022-08-15  8:37       ` Maxime Ripard
2022-08-15  8:37       ` Maxime Ripard
2022-08-15  8:37       ` Maxime Ripard
2022-08-24 16:59       ` Mateusz Kwiatkowski
2022-08-24 16:59         ` Mateusz Kwiatkowski
2022-08-24 16:59         ` Mateusz Kwiatkowski
2022-08-24 16:59         ` Mateusz Kwiatkowski
2022-07-29 16:35 ` [PATCH v1 25/35] drm/sun4i: tv: Remove unused mode_valid Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-30  9:13   ` Jernej Škrabec
2022-07-30  9:13     ` Jernej Škrabec
2022-07-30  9:13     ` Jernej Škrabec
2022-07-30  9:13     ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 26/35] drm/sun4i: tv: Convert to atomic hooks Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-30  9:12   ` Jernej Škrabec
2022-07-30  9:12     ` Jernej Škrabec
2022-07-30  9:12     ` Jernej Škrabec
2022-07-30  9:12     ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 27/35] drm/sun4i: tv: Merge mode_set into atomic_enable Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 28/35] drm/sun4i: tv: Remove useless function Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 29/35] drm/sun4i: tv: Remove useless destroy function Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-30  9:14   ` Jernej Škrabec
2022-07-30  9:14     ` Jernej Škrabec
2022-07-30  9:14     ` Jernej Škrabec
2022-07-30  9:14     ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 30/35] drm/sun4i: tv: Rename error label Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-30  9:15   ` Jernej Škrabec
2022-07-30  9:15     ` Jernej Škrabec
2022-07-30  9:15     ` Jernej Škrabec
2022-07-30  9:15     ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 31/35] drm/sun4i: tv: Add missing reset assertion Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-30  9:16   ` Jernej Škrabec
2022-07-30  9:16     ` Jernej Škrabec
2022-07-30  9:16     ` Jernej Škrabec
2022-07-30  9:16     ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 32/35] drm/sun4i: tv: Convert to the new TV mode property Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-08-28 17:12   ` Noralf Trønnes
2022-08-28 17:12     ` Noralf Trønnes
2022-08-28 17:12     ` Noralf Trønnes
2022-08-28 17:12     ` Noralf Trønnes
2022-07-29 16:35 ` [PATCH v1 33/35] drm/connector: Remove TV modes property Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 20:06   ` kernel test robot
2022-07-29 20:06     ` kernel test robot
2022-07-29 20:06     ` kernel test robot
2022-07-29 20:06     ` kernel test robot
2022-07-29 20:16   ` kernel test robot
2022-07-29 20:16     ` kernel test robot
2022-07-29 20:16     ` kernel test robot
2022-07-29 20:16     ` kernel test robot
2022-07-29 16:35 ` [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-08-12 13:31   ` Geert Uytterhoeven
2022-08-12 13:31     ` Geert Uytterhoeven
2022-08-12 13:31     ` Geert Uytterhoeven
2022-08-12 13:31     ` Geert Uytterhoeven
2022-08-16 13:51     ` Maxime Ripard
2022-08-16 13:51       ` Maxime Ripard
2022-08-16 13:51       ` Maxime Ripard
2022-08-16 13:51       ` Maxime Ripard
2022-08-20 20:18   ` Noralf Trønnes
2022-08-20 20:18     ` Noralf Trønnes
2022-08-20 20:18     ` Noralf Trønnes
2022-08-20 20:18     ` Noralf Trønnes
2022-08-24 15:45     ` Maxime Ripard
2022-08-24 15:45       ` Maxime Ripard
2022-08-24 15:45       ` Maxime Ripard
2022-08-24 15:45       ` Maxime Ripard
2022-08-24 17:08       ` Mateusz Kwiatkowski
2022-08-24 17:08         ` Mateusz Kwiatkowski
2022-08-24 17:08         ` Mateusz Kwiatkowski
2022-08-24 17:08         ` Mateusz Kwiatkowski
2022-08-25 12:41       ` Noralf Trønnes
2022-08-25 12:41         ` Noralf Trønnes
2022-08-25 12:41         ` Noralf Trønnes
2022-08-25 12:41         ` Noralf Trønnes
2022-08-26  6:46         ` Maxime Ripard
2022-08-26  6:46           ` Maxime Ripard
2022-08-26  6:46           ` Maxime Ripard
2022-08-26  6:46           ` Maxime Ripard
2022-08-28 17:06           ` Noralf Trønnes
2022-08-28 17:06             ` Noralf Trønnes
2022-08-28 17:06             ` Noralf Trønnes
2022-08-28 17:06             ` Noralf Trønnes
2022-07-29 16:35 ` [PATCH v1 35/35] drm/modes: Introduce more named modes Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-07-29 16:35   ` Maxime Ripard
2022-08-21 16:16   ` Noralf Trønnes
2022-08-21 16:16     ` Noralf Trønnes
2022-08-21 16:16     ` Noralf Trønnes
2022-08-21 16:16     ` Noralf Trønnes
2022-08-25 14:22     ` Maxime Ripard
2022-08-25 14:22       ` Maxime Ripard
2022-08-25 14:22       ` Maxime Ripard
2022-08-25 14:22       ` Maxime Ripard
2022-08-08 13:03 ` [PATCH v1 00/35] drm: Analog TV Improvements Noralf Trønnes
2022-08-08 13:03   ` Noralf Trønnes
2022-08-08 13:03   ` Noralf Trønnes
2022-08-08 13:03   ` Noralf Trønnes
2022-08-21 16:33 ` Noralf Trønnes
2022-08-21 16:33   ` Noralf Trønnes
2022-08-21 16:33   ` Noralf Trønnes
2022-08-21 16:33   ` Noralf Trønnes
2022-08-22  7:48   ` Maxime Ripard
2022-08-22  7:48     ` Maxime Ripard
2022-08-22  7:48     ` Maxime Ripard
2022-08-22  7:48     ` Maxime Ripard
2022-08-22  8:57     ` Mateusz Kwiatkowski
2022-08-22  8:57       ` Mateusz Kwiatkowski
2022-08-22  8:57       ` Mateusz Kwiatkowski
2022-08-22  8:57       ` Mateusz Kwiatkowski
2022-08-25 15:55       ` Maxime Ripard
2022-08-25 15:55         ` Maxime Ripard
2022-08-25 15:55         ` Maxime Ripard
2022-08-25 15:55         ` Maxime Ripard
2022-08-25 16:17         ` Mateusz Kwiatkowski
2022-08-25 16:17           ` Mateusz Kwiatkowski
2022-08-25 16:17           ` Mateusz Kwiatkowski
2022-08-25 16:17           ` Mateusz Kwiatkowski
2022-08-26  4:07           ` Mateusz Kwiatkowski
2022-08-26  4:07             ` Mateusz Kwiatkowski
2022-08-26  4:07             ` Mateusz Kwiatkowski
2022-08-26  4:07             ` Mateusz Kwiatkowski
2022-08-26  8:39             ` Maxime Ripard
2022-08-26  8:39               ` Maxime Ripard
2022-08-26  8:39               ` Maxime Ripard
2022-08-26  8:39               ` Maxime Ripard
2022-08-26 14:56             ` Dom Cobley
2022-08-26 14:56               ` Dom Cobley
2022-08-26 14:56               ` Dom Cobley
2022-08-26 14:56               ` Dom Cobley
2022-08-27 16:11               ` Noralf Trønnes
2022-08-27 16:11                 ` Noralf Trønnes
2022-08-27 16:11                 ` Noralf Trønnes
2022-08-27 16:11                 ` Noralf Trønnes
2022-08-30 21:31               ` kFYatek
2022-08-30 21:31                 ` kFYatek
2022-08-30 21:31                 ` kFYatek
2022-08-30 21:31                 ` kFYatek
2022-08-22 13:21     ` Noralf Trønnes
2022-08-22 13:21       ` Noralf Trønnes
2022-08-22 13:21       ` Noralf Trønnes
2022-08-22 13:21       ` Noralf Trønnes
2022-08-25 16:21       ` Maxime Ripard
2022-08-25 16:21         ` Maxime Ripard
2022-08-25 16:21         ` Maxime Ripard
2022-08-25 16:21         ` Maxime Ripard
2022-08-25 19:36         ` Noralf Trønnes
2022-08-25 19:36           ` Noralf Trønnes
2022-08-25 19:36           ` Noralf Trønnes
2022-08-25 19:36           ` Noralf Trønnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220818134200.cr22bftmjn226ehn@houat \
    --to=maxime@cerno.tech \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dom@raspberrypi.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=geert@linux-m68k.org \
    --cc=jbrunet@baylibre.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=kfyatek+publicgit@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=narmstrong@baylibre.com \
    --cc=noralf@tronnes.org \
    --cc=p.zabel@pengutronix.de \
    --cc=phil@raspberrypi.com \
    --cc=samuel@sholland.org \
    --cc=tzimmermann@suse.de \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.