Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi, On Sun, Sep 11, 2022 at 06:48:50AM +0200, Mateusz Kwiatkowski wrote: > >> Those extra vbp lines will be treated as a black bar at the top of the > >> frame, > >> and extra vfp lines will be at the bottom of the frame. > >> > >> However if someone specifies e.g. 720x604, there's nothing more you could > >> remove from vfp, so your only option is to reduce vbp compared to the > >> standard > >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will > >> not be > >> centered, the topmost lines will get cropped out, but that's the best we > >> can do > >> and if someone is requesting such resolution, they most likely want to > >> actually > >> access the VBI to e.g. emit teletext. > >> > >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then > >> increases both vfp and vbp proportionately. This puts vsync dead center in > >> the > >> VBI, which is not how it's supposed to be - and that in turn causes the > >> image > >> to be significantly shifted upwards. > >> > >> I hope this makes more sense to you now. > > > > I'm really struggling with this, so thanks for explaining this further > > (and patiently ;)) > > > > If I get this right, what you'd like to change is this part of the > > calculus (simplified a bit, and using PAL, 576i): > > > > vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 > > vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 > > vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > > > > porches = params->num_lines - vactive - vslen; // 43 > > porches_rem = porches - vfp_min - vbp_min; // 32 > > > > vfp = vfp_min + (porches_rem / 2); // 21 > > vbp = porches - vfp; // 22 > > > > Which is indeed having sync centered. > > > > I initially changed it to: > > > > vfp = vfp_min; // 6 > > vbp = num_lines - vactive - vslen - vfp; // 38 > > > > Which is close enough for 576i, but at 480i/50Hz would end up with 134, > > so still fairly far off. > > > > I guess your suggestion would be along the line of: > > > > vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 > > vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38 > > vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > > > > porches = params->num_lines - vactive - vslen; // 0 > > porches_rem = porches - vfp_min - vbp_min; // 0 > > > > vfp = vfp_min + (porches_rem / 2); // 5 > > vbp = porches - vfp; // 38 > > > > Which is still close enough for 576i, but for 480i would end up with: > > > > porches = params->num_lines - vactive - vslen; // 139 > > porches_rem = porches - vfp_min - vbp_min; // 96 > > > > vfp = vfp_min + (porches_rem / 2); // 53 > > vbp = porches - vfp; // 86 > > > > Right? > > Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also > "close enough" to the values I suggested above. > > If you substitute values for true 60 Hz "NTSC" 480i, you should also get > values > that are "close enough" to the official spec. > > The only thing I'd conceptually change is that the 38 lines is not really > "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to > lower > this value if someone wants more active lines than the official 486/576. porches_rem is an int, so if vactive > (num_lines + vslen + vfp_min + vbp_min), porches_rem is going to be negative and we'll remove equally between vfp and vbp to match what's been asked So I believe this should work fine? Maxime signature.asc Description: PGP signature
Re: [Intel-gfx] [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 signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime, 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. Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime, W dniu 7.09.2022 o 16:34, Maxime Ripard pisze: > On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote: >> Hi Maxime, >> >> W dniu 5.09.2022 o 15:37, Maxime Ripard pisze: > + vfp = vfp_min + (porches_rem / 2); > + vbp = porches - vfp; Relative position of the vertical sync within the VBI effectively moves the image up and down. Adding that (porches_rem / 2) moves the image up off center by that many pixels. I'd keep the VFP always at minimum to keep the image centered. >>> >>> And you would increase the back porch only then? >> >> Well, increasing vbp only gives a centered image with the default 480i/576i >> resolutions. However, only ever changing vbp will cause the image to be >> always >> at the bottom of the screen when the active line count is decreased (e.g. >> setting the resolution to 720x480 but for 50Hz "PAL" - like many game >> consoles >> did back in the day). >> >> I believe that the perfect solution would: >> >> - Use the canonical / standard-defined blanking line counts for the standard >> vertical resolutions (480/486/576) >> - Increase vfp and vbp from there by the same number if a smaller number of >> active lines is specified, so that the resulting image is centered >> - Likewise, decrease vfp and vbp by the same number if the active line number >> is larger and there is still leeway (this should allow for seamless >>handling >> of 480i vs. 486i for 60 Hz "NTSC") > > I'm not sure I understand how that's any different than the code you > initially commented on. > > I would start by taking the entire blanking area, remove the sync > period. We only have the two porches now, and I'm starting from the > minimum, adding as many pixels in both (unless it's not an even number, > in which case the backporch will have the extra pixel). > > Isn't it the same thing? > [...] > Unless you only want me to consider the front porch maximum? I think you're confusing the "post-equalizing pulses" with the "vertical back porch" a little bit. The "vertical back porch" includes both the post-equalizing pulses and the entire rest of the VBI period, for the standard resolutions at least. 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) The numbers for vfp don't exactly match the theoretical values, because: - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line mode also on top of VFP_EVEN (not always, but let's not dwell too much) - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN in the 625-line mode - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) defines that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are half-lines that are represented as full lines in the "486i" spec - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines 23-262 and 285-524; see Table 20 on page 26 in https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; this means that the standard 480i frame shaves off four topmost and two bottommost lines (2 and 1 per field) of the 486i full frame Note that the half-line pulses in vfp/vsync may be generated in a different way on encoders other than vc4's VEC. Maybe we should define some concrete semantics for vfp/vsync in analog TV modes, and compensate for that in the drivers. But anyway, that's a separate issue. My point is that, to get a centered image, you can then proportionately add values to those "canonical" vfp/vbp values. For example if someone specifies 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). Those extra vbp lines will be treated as a black bar at the top of the frame, and extra vfp lines will be at the bottom of the frame. However if someone specifies e.g. 720x604, there's nothing more you could remove from vfp, so your only option is to reduce vbp compared to the standard mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be centered, the topmost lines will get cropped out, but that's the best we can do and if someone is requesting such resolution, they most likely want to actually access the VBI to e.g. emit teletext. Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then increases both vfp and vbp proportionately. This puts vsync dead center in the VBI, which is not how it's supposed to be - and that in turn causes the image to be significantly shifted upwards. I hope this makes more sense to you now. Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime, W dniu 9.09.2022 o 15:54, Maxime Ripard pisze: > Hi, > > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > [...] >> I think you're confusing the "post-equalizing pulses" with the "vertical back >> porch" a little bit. The "vertical back porch" includes both the >> post-equalizing >> pulses and the entire rest of the VBI period, for the standard resolutions at >> least. >> >> 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) >> >> The numbers for vfp don't exactly match the theoretical values, because: >> >> - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line >> mode also on top of VFP_EVEN (not always, but let's not dwell too much) >> - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN >> in the 625-line mode >> - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) >> defines >> that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 >>are >> half-lines that are represented as full lines in the "486i" spec > > It's going to be a bit difficult to match that into a drm_display_mode, > since as far I understand it, all the timings are the sum of the timings > of both fields in interlaced. I guess we'll have to be close enough. Well, it's probably the job of the CRTC driver to split the values from drm_display_mode back into separate values for odd and even fields. That's how it's done in the vc4 driver, anyway. > >> - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines >> 23-262 and 285-524; see Table 20 on page 26 in >> >>https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; >> this means that the standard 480i frame shaves off four topmost and two >> bottommost lines (2 and 1 per field) of the 486i full frame > > I'm still struggling a bit to match that into front porch, sync period > and back porch. I guess the sync period is easy since it's pretty much > fixed. That line 0-23 is the entire blanking area though, right? Yes, lines 0-23 is the entire blanking area. And the "back porch" in this context is everything from the start of the sync pulse to the start of active video. It's not just the equalizing pulses. The equalizing pulses have no equivalent in DRM terms. VC4/VEC inserts those automatically and there's no direct control over them, I'm not sure about other encoders. The equalizing pulses are also not essential for the composite video to work. The spec requires them, but most TVs will tolerate them not being there (and early systems like the British 405-line system didn't have any). >> Note that the half-line pulses in vfp/vsync may be generated in a different >> way >> on encoders other than vc4's VEC. Maybe we should define some concrete >> semantics for vfp/vsync in analog TV modes, and compensate for that in the >> drivers. But anyway, that's a separate issue. >> >> My point is that, to get a centered image, you can then proportionately add >> values to those "canonical" vfp/vbp values. For example if someone specifies >> 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). > > In this case, you add 48 both front porches, right? How is that > proportionate? Yes, I meant adding 48 lines to both porches, and I meant "proportionately" as "split equally". Maybe that was an unfortunate choice of words. >> Those extra vbp lines will be treated as a black bar at the top of the frame, >> and extra vfp lines will be at the bottom of the frame. >> >> However if someone specifies e.g. 720x604, there's nothing more you could >> remove from vfp, so your only option is to reduce vbp compared to the >> standard >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not >> be >> centered, the topmost lines will get cropped out, but that's the best we can >> do >> and if someone is requesting such resolution, they most likely want to >> actually >> access the VBI to e.g. emit teletext. >> >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then >> increases both vfp and vbp proportionately. This puts vsync dead center in >> the >> VBI, which is not how it's supposed to be - and that in turn causes the image >> to be significantly shifted upwards. >> >> I hope this makes more sense to you now. > > I'm really struggling with this, so thanks for explaining this further > (and patiently ;)) > > If I get this right, what you'd like to change is this part of the > calculus (simplified a bit, and using PAL, 576i): > > vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 > vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 > vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > > porches = params->num_lines - vactive -
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
> Yes, lines 0-23 is the entire blanking area. And the "back porch" in this > context is everything from the start of the sync pulse to the start of active > video. It's not just the equalizing pulses. I meant "from the end of the sync pulse", obviously. Sorry about the slipup.
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
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? Maxime signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi, On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > W dniu 7.09.2022 o 16:34, Maxime Ripard pisze: > > On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote: > >> Hi Maxime, > >> > >> W dniu 5.09.2022 o 15:37, Maxime Ripard pisze: > > + vfp = vfp_min + (porches_rem / 2); > > + vbp = porches - vfp; > > Relative position of the vertical sync within the VBI effectively moves > the > image up and down. Adding that (porches_rem / 2) moves the image up off > center > by that many pixels. I'd keep the VFP always at minimum to keep the image > centered. > >>> > >>> And you would increase the back porch only then? > >> > >> Well, increasing vbp only gives a centered image with the default 480i/576i > >> resolutions. However, only ever changing vbp will cause the image to be > >> always > >> at the bottom of the screen when the active line count is decreased (e.g. > >> setting the resolution to 720x480 but for 50Hz "PAL" - like many game > >> consoles > >> did back in the day). > >> > >> I believe that the perfect solution would: > >> > >> - Use the canonical / standard-defined blanking line counts for the > >> standard > >> vertical resolutions (480/486/576) > >> - Increase vfp and vbp from there by the same number if a smaller number of > >> active lines is specified, so that the resulting image is centered > >> - Likewise, decrease vfp and vbp by the same number if the active line > >> number > >> is larger and there is still leeway (this should allow for seamless > >>handling > >> of 480i vs. 486i for 60 Hz "NTSC") > > > > I'm not sure I understand how that's any different than the code you > > initially commented on. > > > > I would start by taking the entire blanking area, remove the sync > > period. We only have the two porches now, and I'm starting from the > > minimum, adding as many pixels in both (unless it's not an even number, > > in which case the backporch will have the extra pixel). > > > > Isn't it the same thing? > > [...] > > Unless you only want me to consider the front porch maximum? > > I think you're confusing the "post-equalizing pulses" with the "vertical back > porch" a little bit. The "vertical back porch" includes both the > post-equalizing > pulses and the entire rest of the VBI period, for the standard resolutions at > least. > > 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) > > The numbers for vfp don't exactly match the theoretical values, because: > > - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line > mode also on top of VFP_EVEN (not always, but let's not dwell too much) > - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN > in the 625-line mode > - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) > defines > that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are > half-lines that are represented as full lines in the "486i" spec It's going to be a bit difficult to match that into a drm_display_mode, since as far I understand it, all the timings are the sum of the timings of both fields in interlaced. I guess we'll have to be close enough. > - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines > 23-262 and 285-524; see Table 20 on page 26 in > > https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; > this means that the standard 480i frame shaves off four topmost and two > bottommost lines (2 and 1 per field) of the 486i full frame I'm still struggling a bit to match that into front porch, sync period and back porch. I guess the sync period is easy since it's pretty much fixed. That line 0-23 is the entire blanking area though, right? > Note that the half-line pulses in vfp/vsync may be generated in a different > way > on encoders other than vc4's VEC. Maybe we should define some concrete > semantics for vfp/vsync in analog TV modes, and compensate for that in the > drivers. But anyway, that's a separate issue. > > My point is that, to get a centered image, you can then proportionately add > values to those "canonical" vfp/vbp values. For example if someone specifies > 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). In this case, you add 48 both front porches, right? How is that proportionate? > Those extra vbp lines will be treated as a black bar at the top of the frame, > and extra vfp lines will be at the bottom of the frame. > > However if someone specifies e.g. 720x604, there's nothing more you could > remove from vfp, so your only option is to reduce vbp compared to the standard > mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be > centered, the
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi,
On Tue, Aug 30, 2022 at 10:01:11AM -0300, Maíra Canal wrote:
> On 8/29/22 10:11, Maxime Ripard wrote:
> > Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> > 625-lines modes in their drivers.
> >
> > Since those modes are fairly standard, and that we'll need to use them
> > in more places in the future, it makes sense to move their definition
> > into the core framework.
> >
> > However, analog display usually have fairly loose timings requirements,
> > the only discrete parameters being the total number of lines and pixel
> > clock frequency. Thus, we created a function that will create a display
> > mode from the standard, the pixel frequency and the active area.
> >
> > Signed-off-by: Maxime Ripard
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 304004fb80aa..ee581ee17171 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -116,6 +116,459 @@ void drm_mode_probed_add(struct drm_connector
> > *connector,
> > }
> > EXPORT_SYMBOL(drm_mode_probed_add);
> >
> > +enum drm_mode_analog {
> > + DRM_MODE_ANALOG_NTSC,
> > + DRM_MODE_ANALOG_PAL,
> > +};
> > +
> > +/*
> > + * The timings come from:
> > + * -
> > https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
> > + * -
> > https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
> > + * -
> > https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
> > + */
> > +#define NTSC_LINE_DURATION_NS 63556U
> > +#define NTSC_LINES_NUMBER 525
> > +
> > +#define NTSC_HBLK_DURATION_TYP_NS 10900U
> > +#define NTSC_HBLK_DURATION_MIN_NS (NTSC_HBLK_DURATION_TYP_NS - 200)
> > +#define NTSC_HBLK_DURATION_MAX_NS (NTSC_HBLK_DURATION_TYP_NS + 200)
> > +
> > +#define NTSC_HACT_DURATION_TYP_NS (NTSC_LINE_DURATION_NS -
> > NTSC_HBLK_DURATION_TYP_NS)
> > +#define NTSC_HACT_DURATION_MIN_NS (NTSC_LINE_DURATION_NS -
> > NTSC_HBLK_DURATION_MAX_NS)
> > +#define NTSC_HACT_DURATION_MAX_NS (NTSC_LINE_DURATION_NS -
> > NTSC_HBLK_DURATION_MIN_NS)
> > +
> > +#define NTSC_HFP_DURATION_TYP_NS 1500
> > +#define NTSC_HFP_DURATION_MIN_NS 1270
> > +#define NTSC_HFP_DURATION_MAX_NS 2220
> > +
> > +#define NTSC_HSLEN_DURATION_TYP_NS 4700
> > +#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
> > +#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
> > +
> > +#define NTSC_HBP_DURATION_TYP_NS 4700
> > +
> > +/*
> > + * I couldn't find the actual tolerance for the back porch, so let's
> > + * just reuse the sync length ones.
> > + */
> > +#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
> > +#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
> > +
> > +#define PAL_LINE_DURATION_NS 64000U
> > +#define PAL_LINES_NUMBER 625
> > +
> > +#define PAL_HACT_DURATION_TYP_NS 51950U
> > +#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
> > +#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
> > +
> > +#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
> > PAL_HACT_DURATION_TYP_NS)
> > +#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
> > PAL_HACT_DURATION_MAX_NS)
> > +#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
> > PAL_HACT_DURATION_MIN_NS)
> > +
> > +#define PAL_HFP_DURATION_TYP_NS1650
> > +#define PAL_HFP_DURATION_MIN_NS(PAL_HFP_DURATION_TYP_NS - 100)
> > +#define PAL_HFP_DURATION_MAX_NS(PAL_HFP_DURATION_TYP_NS + 400)
> > +
> > +#define PAL_HSLEN_DURATION_TYP_NS 4700
> > +#define PAL_HSLEN_DURATION_MIN_NS (PAL_HSLEN_DURATION_TYP_NS - 200)
> > +#define PAL_HSLEN_DURATION_MAX_NS (PAL_HSLEN_DURATION_TYP_NS + 200)
> > +
> > +#define PAL_HBP_DURATION_TYP_NS5700
> > +#define PAL_HBP_DURATION_MIN_NS(PAL_HBP_DURATION_TYP_NS - 200)
> > +#define PAL_HBP_DURATION_MAX_NS(PAL_HBP_DURATION_TYP_NS + 200)
> > +
> > +#define PAL_VFP_INTERLACE_LINES5
> > +#define PAL_VSLEN_INTERLACE_LINES 5
> > +
> > +#define PAL_SHORT_SYNC_DURATION_NS ((2 + 30) * NSEC_PER_USEC)
> > +#define PAL_LONG_SYNC_DURATION_NS ((30 + 2) * NSEC_PER_USEC)
> > +
> > +struct analog_param_field {
> > + unsigned int even, odd;
> > +};
> > +
> > +#define PARAM_FIELD(_odd, _even) \
> > + { .even = _even, .odd = _odd }
> > +
> > +struct analog_param_range {
> > + unsigned intmin, typ, max;
> > +};
> > +
> > +#define PARAM_RANGE(_min, _typ, _max) \
> > + { .min = _min, .typ = _typ, .max = _max }
> > +
> > +struct analog_parameters {
> > + unsigned intnum_lines;
> > + unsigned intline_duration_ns;
> > +
> > + struct analog_param_range hact_ns;
> > + struct analog_param_range hfp_ns;
> > + struct analog_param_range hslen_ns;
> > + struct analog_param_range
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
On Mon, Sep 05, 2022 at 06:32:14PM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
>
> W dniu 5.09.2022 o 15:32, Maxime Ripard pisze:
> > Hi,
> >
> > On Wed, Aug 31, 2022 at 10:14:28AM +0200, Geert Uytterhoeven wrote:
> +enum drm_mode_analog {
> + DRM_MODE_ANALOG_NTSC,
> + DRM_MODE_ANALOG_PAL,
> +};
> >>>
> >>> Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is
> >>> common,
> >>> but strictly speaking a misnomer. Those are color encoding systems, and
> >>> your
> >>> patchset fully supports lesser used, but standard encodings for those
> >>> (e.g.
> >>> PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more
> >>> neutral
> >>> naming scheme. Some ideas:
> >>>
> >>> - DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh
> >>> rate)
> >>> - DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard
> >>> line
> >>> count)
> >>
> >> IMHO these are bad names, as e.g. VGA640x480@60 is also analog, using
> >> 60 Hz and 525 lines. Add "TV" to the name?
> >>
> >>> - DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU
> >>> System
> >>> Letter Designations)
> >>
> >> Or DRM_MODE_ITU_*?
> >> But given the long list of letters, this looks fragile to me.
> >
> > Does it matter at all? It's an internal API that isn't exposed at all.
> > I'd rather have a common name that everyone can understand in this case
> > rather than a *perfect* name where most will scratch their head
> > wondering what it's about.
>
> You may have a point. But in that case, maybe it'd make sense to at least add
> a short comment explaining what do you mean by "NTSC" and "PAL" in this
> context?
Consider it done :)
Maxime
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote: > Hi Maxime, > > W dniu 5.09.2022 o 15:37, Maxime Ripard pisze: > >>> + vfp = vfp_min + (porches_rem / 2); > >>> + vbp = porches - vfp; > >> > >> Relative position of the vertical sync within the VBI effectively moves the > >> image up and down. Adding that (porches_rem / 2) moves the image up off > >> center > >> by that many pixels. I'd keep the VFP always at minimum to keep the image > >> centered. > > > > And you would increase the back porch only then? > > Well, increasing vbp only gives a centered image with the default 480i/576i > resolutions. However, only ever changing vbp will cause the image to be always > at the bottom of the screen when the active line count is decreased (e.g. > setting the resolution to 720x480 but for 50Hz "PAL" - like many game consoles > did back in the day). > > I believe that the perfect solution would: > > - Use the canonical / standard-defined blanking line counts for the standard > vertical resolutions (480/486/576) > - Increase vfp and vbp from there by the same number if a smaller number of > active lines is specified, so that the resulting image is centered > - Likewise, decrease vfp and vbp by the same number if the active line number > is larger and there is still leeway (this should allow for seamless handling > of 480i vs. 486i for 60 Hz "NTSC") I'm not sure I understand how that's any different than the code you initially commented on. I would start by taking the entire blanking area, remove the sync period. We only have the two porches now, and I'm starting from the minimum, adding as many pixels in both (unless it's not an even number, in which case the backporch will have the extra pixel). Isn't it the same thing? > - If even more active lines are specified, once the limit for vfp is hit, then > decrease vbp only - the resulting image will definitely be off-center, but > there's no other way Unless you only want me to consider the front porch maximum? Maxime signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime, W dniu 5.09.2022 o 15:37, Maxime Ripard pisze: >>> + vfp = vfp_min + (porches_rem / 2); >>> + vbp = porches - vfp; >> >> Relative position of the vertical sync within the VBI effectively moves the >> image up and down. Adding that (porches_rem / 2) moves the image up off >> center >> by that many pixels. I'd keep the VFP always at minimum to keep the image >> centered. > > And you would increase the back porch only then? Well, increasing vbp only gives a centered image with the default 480i/576i resolutions. However, only ever changing vbp will cause the image to be always at the bottom of the screen when the active line count is decreased (e.g. setting the resolution to 720x480 but for 50Hz "PAL" - like many game consoles did back in the day). I believe that the perfect solution would: - Use the canonical / standard-defined blanking line counts for the standard vertical resolutions (480/486/576) - Increase vfp and vbp from there by the same number if a smaller number of active lines is specified, so that the resulting image is centered - Likewise, decrease vfp and vbp by the same number if the active line number is larger and there is still leeway (this should allow for seamless handling of 480i vs. 486i for 60 Hz "NTSC") - If even more active lines are specified, once the limit for vfp is hit, then decrease vbp only - the resulting image will definitely be off-center, but there's no other way I hope this makes sense for you as well. Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime,
W dniu 5.09.2022 o 15:32, Maxime Ripard pisze:
> Hi,
>
> On Wed, Aug 31, 2022 at 10:14:28AM +0200, Geert Uytterhoeven wrote:
+enum drm_mode_analog {
+ DRM_MODE_ANALOG_NTSC,
+ DRM_MODE_ANALOG_PAL,
+};
>>>
>>> Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is
>>> common,
>>> but strictly speaking a misnomer. Those are color encoding systems, and your
>>> patchset fully supports lesser used, but standard encodings for those (e.g.
>>> PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more
>>> neutral
>>> naming scheme. Some ideas:
>>>
>>> - DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh
>>> rate)
>>> - DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
>>> count)
>>
>> IMHO these are bad names, as e.g. VGA640x480@60 is also analog, using
>> 60 Hz and 525 lines. Add "TV" to the name?
>>
>>> - DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU
>>> System
>>> Letter Designations)
>>
>> Or DRM_MODE_ITU_*?
>> But given the long list of letters, this looks fragile to me.
>
> Does it matter at all? It's an internal API that isn't exposed at all.
> I'd rather have a common name that everyone can understand in this case
> rather than a *perfect* name where most will scratch their head
> wondering what it's about.
You may have a point. But in that case, maybe it'd make sense to at least add
a short comment explaining what do you mean by "NTSC" and "PAL" in this context?
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime,
Wow. That's an enormous amount of effort put into this patch.
But I'm tempted to say that this is actually overengineered quite a bit :D
Considering that there's no way to access all these calculations from user
space, and I can't imagine anybody using anything else than those standard
480i/576i (and maybe 240p/288p) modes at 13.5 MHz any time soon... I'm not
sure if we actually need all this.
But anyway, I'm not the maintainer of this subsystem, so I'm not the one to
decide.
> +enum drm_mode_analog {
> + DRM_MODE_ANALOG_NTSC,
> + DRM_MODE_ANALOG_PAL,
> +};
Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is common,
but strictly speaking a misnomer. Those are color encoding systems, and your
patchset fully supports lesser used, but standard encodings for those (e.g.
PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more neutral
naming scheme. Some ideas:
- DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh rate)
- DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
count)
- DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU System
Letter Designations)
> +#define NTSC_HFP_DURATION_TYP_NS 1500
> +#define NTSC_HFP_DURATION_MIN_NS 1270
> +#define NTSC_HFP_DURATION_MAX_NS 2220
You've defined those min/typ/max ranges, but you're not using the "typ" field
for anything other than hslen. The actual "typical" value is thus always the
midpoint, which isn't necessarily the best choice.
In particular, for the standard 720px wide modes at 13.5 MHz, hsync_start
ends up being 735 for 480i and 734 for 576i, instead of 736 and 732 requested
by BT.601. That's all obviously within tolerances, but the image ends up
noticeably off-center (at least on modern TVs), especially in the 576i case.
> + htotal = params->line_duration_ns * pixel_clock_hz / NSEC_PER_SEC;
You're multiplying an unsigned int and an unsigned long - both types are only
required to be 32 bit, so this is likely to overflow. You need to use a cast to
unsigned long long, and then call do_div() for 64-bit division.
This actually overflowed on me on my Pi running ARM32 kernel, resulting in
negative horizontal porch lengths, and drm_helper_probe_add_cmdline_mode()
taking over the mode generation (badly), and a horrible mess on screen.
> + vfp = vfp_min + (porches_rem / 2);
> + vbp = porches - vfp;
Relative position of the vertical sync within the VBI effectively moves the
image up and down. Adding that (porches_rem / 2) moves the image up off center
by that many pixels. I'd keep the VFP always at minimum to keep the image
centered.
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
>
> 625-lines modes in their drivers.
>
>
>
> Since those modes are fairly standard, and that we'll need to use them
>
> in more places in the future, it makes sense to move their definition
>
> into the core framework.
>
>
>
> However, analog display usually have fairly loose timings requirements,
>
> the only discrete parameters being the total number of lines and pixel
>
> clock frequency. Thus, we created a function that will create a display
>
> mode from the standard, the pixel frequency and the active area.
>
>
>
> Signed-off-by: Maxime Ripard
>
On a 32-bit build I'm getting bogus modes:
[ 249.57] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:45:Composite-1]
[ 249.600198] [drm:drm_mode_debug_printmodeline] Modeline "720x480i":
17143 13500 720 308 372 3 480 499 505 525 0x40 0x1a
[ 249.600292] [drm:drm_mode_prune_invalid] Not using 720x480i mode:
H_ILLEGAL
[ 249.600317] [drm:drm_mode_debug_printmodeline] Modeline "720x576i": 0
13500 720 302 366 0 576 597 603 625 0x40 0x1a
[ 249.600349] [drm:drm_mode_prune_invalid] Not using 720x576i mode:
H_ILLEGAL
[ 249.600374] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:45:Composite-1] probed modes :
[ 249.600453] [drm:drm_mode_debug_printmodeline] Modeline "720x240i":
60 27800 720 736 808 896 240 241 244 516 0x20 0x6
It's fine on 64-bit.
Noralf.
>
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>
> index 304004fb80aa..ee581ee17171 100644
>
> --- a/drivers/gpu/drm/drm_modes.c
>
> +++ b/drivers/gpu/drm/drm_modes.c
>
> @@ -116,6 +116,459 @@ void drm_mode_probed_add(struct drm_connector
> *connector,
>
> }
>
> EXPORT_SYMBOL(drm_mode_probed_add);
>
>
>
> +enum drm_mode_analog {
>
> + DRM_MODE_ANALOG_NTSC,
>
> + DRM_MODE_ANALOG_PAL,
>
> +};
>
> +
>
> +/*
>
> + * The timings come from:
>
> + * -
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
>
> + * -
> https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
>
> + * -
> https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
>
> + */
>
> +#define NTSC_LINE_DURATION_NS63556U
>
> +#define NTSC_LINES_NUMBER525
>
> +
>
> +#define NTSC_HBLK_DURATION_TYP_NS10900U
>
> +#define NTSC_HBLK_DURATION_MIN_NS(NTSC_HBLK_DURATION_TYP_NS - 200)
>
> +#define NTSC_HBLK_DURATION_MAX_NS(NTSC_HBLK_DURATION_TYP_NS + 200)
>
> +
>
> +#define NTSC_HACT_DURATION_TYP_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_TYP_NS)
>
> +#define NTSC_HACT_DURATION_MIN_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MAX_NS)
>
> +#define NTSC_HACT_DURATION_MAX_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MIN_NS)
>
> +
>
> +#define NTSC_HFP_DURATION_TYP_NS 1500
>
> +#define NTSC_HFP_DURATION_MIN_NS 1270
>
> +#define NTSC_HFP_DURATION_MAX_NS 2220
>
> +
>
> +#define NTSC_HSLEN_DURATION_TYP_NS 4700
>
> +#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
>
> +#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
>
> +
>
> +#define NTSC_HBP_DURATION_TYP_NS 4700
>
> +
>
> +/*
>
> + * I couldn't find the actual tolerance for the back porch, so let's
>
> + * just reuse the sync length ones.
>
> + */
>
> +#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
>
> +#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
>
> +
>
> +#define PAL_LINE_DURATION_NS 64000U
>
> +#define PAL_LINES_NUMBER 625
>
> +
>
> +#define PAL_HACT_DURATION_TYP_NS 51950U
>
> +#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
>
> +#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
>
> +
>
> +#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_TYP_NS)
>
> +#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_MAX_NS)
>
> +#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_MIN_NS)
>
> +
>
> +#define PAL_HFP_DURATION_TYP_NS 1650
>
> +#define PAL_HFP_DURATION_MIN_NS (PAL_HFP_DURATION_TYP_NS - 100)
>
> +#define PAL_HFP_DURATION_MAX_NS (PAL_HFP_DURATION_TYP_NS + 400)
>
> +
>
> +#define PAL_HSLEN_DURATION_TYP_NS4700
>
> +#define PAL_HSLEN_DURATION_MIN_NS(PAL_HSLEN_DURATION_TYP_NS - 200)
>
> +#define PAL_HSLEN_DURATION_MAX_NS(PAL_HSLEN_DURATION_TYP_NS + 200)
>
> +
>
> +#define PAL_HBP_DURATION_TYP_NS 5700
>
> +#define PAL_HBP_DURATION_MIN_NS (PAL_HBP_DURATION_TYP_NS - 200)
>
> +#define PAL_HBP_DURATION_MAX_NS (PAL_HBP_DURATION_TYP_NS + 200)
>
> +
>
> +#define PAL_VFP_INTERLACE_LINES 5
>
> +#define
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi, On Wed, Aug 31, 2022 at 03:44:52AM +0200, Mateusz Kwiatkowski wrote: > > +#define NTSC_HFP_DURATION_TYP_NS 1500 > > +#define NTSC_HFP_DURATION_MIN_NS 1270 > > +#define NTSC_HFP_DURATION_MAX_NS 2220 > > You've defined those min/typ/max ranges, but you're not using the "typ" field > for anything other than hslen. Yeah... I've left most of them because it was so hard to find most of them, it's useful at least for documentation purposes. And it's a define so there's pretty much no downside to it as far as the final binary is involved. > The actual "typical" value is thus always the midpoint, which isn't > necessarily the best choice. > > In particular, for the standard 720px wide modes at 13.5 MHz, hsync_start > ends up being 735 for 480i and 734 for 576i, instead of 736 and 732 requested > by BT.601. That's all obviously within tolerances, but the image ends up > noticeably off-center (at least on modern TVs), especially in the 576i case. I'll try to fix that up. > > + htotal = params->line_duration_ns * pixel_clock_hz / NSEC_PER_SEC; > > You're multiplying an unsigned int and an unsigned long - both types are only > required to be 32 bit, so this is likely to overflow. You need to use a cast > to > unsigned long long, and then call do_div() for 64-bit division. > > This actually overflowed on me on my Pi running ARM32 kernel, resulting in > negative horizontal porch lengths, and drm_helper_probe_add_cmdline_mode() > taking over the mode generation (badly), and a horrible mess on screen. Indeed, that's bad. > > + vfp = vfp_min + (porches_rem / 2); > > + vbp = porches - vfp; > > Relative position of the vertical sync within the VBI effectively moves the > image up and down. Adding that (porches_rem / 2) moves the image up off center > by that many pixels. I'd keep the VFP always at minimum to keep the image > centered. And you would increase the back porch only then? Maxime signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi,
On Wed, Aug 31, 2022 at 10:14:28AM +0200, Geert Uytterhoeven wrote:
> > > +enum drm_mode_analog {
> > > +DRM_MODE_ANALOG_NTSC,
> > > +DRM_MODE_ANALOG_PAL,
> > > +};
> >
> > Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is
> > common,
> > but strictly speaking a misnomer. Those are color encoding systems, and your
> > patchset fully supports lesser used, but standard encodings for those (e.g.
> > PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more
> > neutral
> > naming scheme. Some ideas:
> >
> > - DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh
> > rate)
> > - DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
> > count)
>
> IMHO these are bad names, as e.g. VGA640x480@60 is also analog, using
> 60 Hz and 525 lines. Add "TV" to the name?
>
> > - DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU
> > System
> > Letter Designations)
>
> Or DRM_MODE_ITU_*?
> But given the long list of letters, this looks fragile to me.
Does it matter at all? It's an internal API that isn't exposed at all.
I'd rather have a common name that everyone can understand in this case
rather than a *perfect* name where most will scratch their head
wondering what it's about.
Maxime
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Mateusz,
On Wed, Aug 31, 2022 at 3:44 AM Mateusz Kwiatkowski wrote:
> Wow. That's an enormous amount of effort put into this patch.
>
> But I'm tempted to say that this is actually overengineered quite a bit :D
> Considering that there's no way to access all these calculations from user
> space, and I can't imagine anybody using anything else than those standard
> 480i/576i (and maybe 240p/288p) modes at 13.5 MHz any time soon... I'm not
> sure if we actually need all this.
We'll need it when we get an Amiga DRM driver, which will use
7/14/28 MHz pixel clocks.
> But anyway, I'm not the maintainer of this subsystem, so I'm not the one to
> decide.
>
> > +enum drm_mode_analog {
> > +DRM_MODE_ANALOG_NTSC,
> > +DRM_MODE_ANALOG_PAL,
> > +};
>
> Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is
> common,
> but strictly speaking a misnomer. Those are color encoding systems, and your
> patchset fully supports lesser used, but standard encodings for those (e.g.
> PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more neutral
> naming scheme. Some ideas:
>
> - DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh rate)
> - DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
> count)
IMHO these are bad names, as e.g. VGA640x480@60 is also analog, using
60 Hz and 525 lines. Add "TV" to the name?
> - DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU
> System
> Letter Designations)
Or DRM_MODE_ITU_*?
But given the long list of letters, this looks fragile to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime,
On 8/29/22 10:11, Maxime Ripard wrote:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> 625-lines modes in their drivers.
>
> Since those modes are fairly standard, and that we'll need to use them
> in more places in the future, it makes sense to move their definition
> into the core framework.
>
> However, analog display usually have fairly loose timings requirements,
> the only discrete parameters being the total number of lines and pixel
> clock frequency. Thus, we created a function that will create a display
> mode from the standard, the pixel frequency and the active area.
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 304004fb80aa..ee581ee17171 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -116,6 +116,459 @@ void drm_mode_probed_add(struct drm_connector
> *connector,
> }
> EXPORT_SYMBOL(drm_mode_probed_add);
>
> +enum drm_mode_analog {
> + DRM_MODE_ANALOG_NTSC,
> + DRM_MODE_ANALOG_PAL,
> +};
> +
> +/*
> + * The timings come from:
> + * -
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
> + * -
> https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
> + * -
> https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
> + */
> +#define NTSC_LINE_DURATION_NS63556U
> +#define NTSC_LINES_NUMBER525
> +
> +#define NTSC_HBLK_DURATION_TYP_NS10900U
> +#define NTSC_HBLK_DURATION_MIN_NS(NTSC_HBLK_DURATION_TYP_NS - 200)
> +#define NTSC_HBLK_DURATION_MAX_NS(NTSC_HBLK_DURATION_TYP_NS + 200)
> +
> +#define NTSC_HACT_DURATION_TYP_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_TYP_NS)
> +#define NTSC_HACT_DURATION_MIN_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MAX_NS)
> +#define NTSC_HACT_DURATION_MAX_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MIN_NS)
> +
> +#define NTSC_HFP_DURATION_TYP_NS 1500
> +#define NTSC_HFP_DURATION_MIN_NS 1270
> +#define NTSC_HFP_DURATION_MAX_NS 2220
> +
> +#define NTSC_HSLEN_DURATION_TYP_NS 4700
> +#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
> +#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
> +
> +#define NTSC_HBP_DURATION_TYP_NS 4700
> +
> +/*
> + * I couldn't find the actual tolerance for the back porch, so let's
> + * just reuse the sync length ones.
> + */
> +#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
> +#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
> +
> +#define PAL_LINE_DURATION_NS 64000U
> +#define PAL_LINES_NUMBER 625
> +
> +#define PAL_HACT_DURATION_TYP_NS 51950U
> +#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
> +#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
> +
> +#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_TYP_NS)
> +#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_MAX_NS)
> +#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_MIN_NS)
> +
> +#define PAL_HFP_DURATION_TYP_NS 1650
> +#define PAL_HFP_DURATION_MIN_NS (PAL_HFP_DURATION_TYP_NS - 100)
> +#define PAL_HFP_DURATION_MAX_NS (PAL_HFP_DURATION_TYP_NS + 400)
> +
> +#define PAL_HSLEN_DURATION_TYP_NS4700
> +#define PAL_HSLEN_DURATION_MIN_NS(PAL_HSLEN_DURATION_TYP_NS - 200)
> +#define PAL_HSLEN_DURATION_MAX_NS(PAL_HSLEN_DURATION_TYP_NS + 200)
> +
> +#define PAL_HBP_DURATION_TYP_NS 5700
> +#define PAL_HBP_DURATION_MIN_NS (PAL_HBP_DURATION_TYP_NS - 200)
> +#define PAL_HBP_DURATION_MAX_NS (PAL_HBP_DURATION_TYP_NS + 200)
> +
> +#define PAL_VFP_INTERLACE_LINES 5
> +#define PAL_VSLEN_INTERLACE_LINES5
> +
> +#define PAL_SHORT_SYNC_DURATION_NS ((2 + 30) * NSEC_PER_USEC)
> +#define PAL_LONG_SYNC_DURATION_NS((30 + 2) * NSEC_PER_USEC)
> +
> +struct analog_param_field {
> + unsigned int even, odd;
> +};
> +
> +#define PARAM_FIELD(_odd, _even) \
> + { .even = _even, .odd = _odd }
> +
> +struct analog_param_range {
> + unsigned intmin, typ, max;
> +};
> +
> +#define PARAM_RANGE(_min, _typ, _max)\
> + { .min = _min, .typ = _typ, .max = _max }
> +
> +struct analog_parameters {
> + unsigned intnum_lines;
> + unsigned intline_duration_ns;
> +
> + struct analog_param_range hact_ns;
> + struct analog_param_range hfp_ns;
> + struct analog_param_range hslen_ns;
> + struct analog_param_range hbp_ns;
> + struct analog_param_range hblk_ns;
> +
> + struct analog_param_field vfp_lines;
> + struct analog_param_field vslen_lines;
> + struct analog_param_field
[Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency. Thus, we created a function that will create a display
mode from the standard, the pixel frequency and the active area.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..ee581ee17171 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -116,6 +116,459 @@ void drm_mode_probed_add(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_mode_probed_add);
+enum drm_mode_analog {
+ DRM_MODE_ANALOG_NTSC,
+ DRM_MODE_ANALOG_PAL,
+};
+
+/*
+ * The timings come from:
+ * -
https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
+ * -
https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
+ * -
https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
+ */
+#define NTSC_LINE_DURATION_NS 63556U
+#define NTSC_LINES_NUMBER 525
+
+#define NTSC_HBLK_DURATION_TYP_NS 10900U
+#define NTSC_HBLK_DURATION_MIN_NS (NTSC_HBLK_DURATION_TYP_NS - 200)
+#define NTSC_HBLK_DURATION_MAX_NS (NTSC_HBLK_DURATION_TYP_NS + 200)
+
+#define NTSC_HACT_DURATION_TYP_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_TYP_NS)
+#define NTSC_HACT_DURATION_MIN_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_MAX_NS)
+#define NTSC_HACT_DURATION_MAX_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_MIN_NS)
+
+#define NTSC_HFP_DURATION_TYP_NS 1500
+#define NTSC_HFP_DURATION_MIN_NS 1270
+#define NTSC_HFP_DURATION_MAX_NS 2220
+
+#define NTSC_HSLEN_DURATION_TYP_NS 4700
+#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
+#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
+
+#define NTSC_HBP_DURATION_TYP_NS 4700
+
+/*
+ * I couldn't find the actual tolerance for the back porch, so let's
+ * just reuse the sync length ones.
+ */
+#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
+#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
+
+#define PAL_LINE_DURATION_NS 64000U
+#define PAL_LINES_NUMBER 625
+
+#define PAL_HACT_DURATION_TYP_NS 51950U
+#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
+#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
+
+#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_TYP_NS)
+#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_MAX_NS)
+#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_MIN_NS)
+
+#define PAL_HFP_DURATION_TYP_NS1650
+#define PAL_HFP_DURATION_MIN_NS(PAL_HFP_DURATION_TYP_NS - 100)
+#define PAL_HFP_DURATION_MAX_NS(PAL_HFP_DURATION_TYP_NS + 400)
+
+#define PAL_HSLEN_DURATION_TYP_NS 4700
+#define PAL_HSLEN_DURATION_MIN_NS (PAL_HSLEN_DURATION_TYP_NS - 200)
+#define PAL_HSLEN_DURATION_MAX_NS (PAL_HSLEN_DURATION_TYP_NS + 200)
+
+#define PAL_HBP_DURATION_TYP_NS5700
+#define PAL_HBP_DURATION_MIN_NS(PAL_HBP_DURATION_TYP_NS - 200)
+#define PAL_HBP_DURATION_MAX_NS(PAL_HBP_DURATION_TYP_NS + 200)
+
+#define PAL_VFP_INTERLACE_LINES5
+#define PAL_VSLEN_INTERLACE_LINES 5
+
+#define PAL_SHORT_SYNC_DURATION_NS ((2 + 30) * NSEC_PER_USEC)
+#define PAL_LONG_SYNC_DURATION_NS ((30 + 2) * NSEC_PER_USEC)
+
+struct analog_param_field {
+ unsigned int even, odd;
+};
+
+#define PARAM_FIELD(_odd, _even) \
+ { .even = _even, .odd = _odd }
+
+struct analog_param_range {
+ unsigned intmin, typ, max;
+};
+
+#define PARAM_RANGE(_min, _typ, _max) \
+ { .min = _min, .typ = _typ, .max = _max }
+
+struct analog_parameters {
+ unsigned intnum_lines;
+ unsigned intline_duration_ns;
+
+ struct analog_param_range hact_ns;
+ struct analog_param_range hfp_ns;
+ struct analog_param_range hslen_ns;
+ struct analog_param_range hbp_ns;
+ struct analog_param_range hblk_ns;
+
+ struct analog_param_field vfp_lines;
+ struct analog_param_field vslen_lines;
+ struct analog_param_field vbp_lines;
+};
+
+#define TV_MODE_PARAMETER(_mode, _lines, _line_dur, _hact, _hfp, _hslen, _hbp,
_hblk, _vfp, _vslen, _vbp) \
+ [_mode] = { \
+
