*[PATCH v5 00/12] drm/vc4: Allow for more boot-time configuration@ 2019-06-17 14:51 Maxime Ripard
2019-06-17 14:51 ` [PATCH v5 01/12] drm/connector: Add documentation for drm_cmdline_mode Maxime Ripard
` (11 more replies)0 siblings, 12 replies; 28+ messages in thread
From: Maxime Ripard @ 2019-06-17 14:51 UTC (permalink / raw)
To: Maarten Lankhorst, Sean Paul, Maxime Ripard, Daniel Vetter, David Airlie
Cc: eben, dri-devel, Paul Kocialkowski, Eric Anholt, noralf,
Thomas Petazzoni, linux-arm-kernel
Hi,
The proprietary stack for the RaspberryPi allows for a number of video
parameters widely used by their users, but yet don't have any equivalents
in the mainline kernel.
Those options are detailed here:
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md
While not all of them are desirable to have in the mainline kernel, some of
them still have value, such as properties to initialise the overscan or
rotation parameters.
This series is an attempt to support those, and is based on a rewrite of
the command line parser I did a couple of years ago that never reached
upstream (due to a lack of time on my side). While this parser was
initially made to deal with named modes (in order to support TV modes), it
also allowed to extend it more easily, which is why it's resurrected.
It relies on the series "drm/fb-helper: Move modesetting code to
drm_client" by Noralf Trønnes found here:
https://patchwork.freedesktop.org/series/58598/
Let me know what you think,
Maxime
Changes from v4:
- Change the name of the variable to make it clear it's about reflection
and rotation.
- Fix the reflection case in drm_client_rotation
- Fix the documentation accordingly
- Added missing modedb.rst documentation
- Fix a chunk not in the proper commit
- Fix a few typos
- Rebased on top of current next
Changes from v3:
- Add documentation for drm_cmdline_mode and the new variables
- Move the TV properties reset to a helper
- Fix a missing X resolution or a missing Y resolution
- Add more tests
- Add the rotation to the orientation
- Fix the reflection
- Change the name of the drm_client_panel_rotation function
- Rebased on top of current next
Changes from v2:
- Fixed some sparse warnings
- Rebased on top of next and Noralf series
- Moved the property initialisation to vc4 reset hook
- Added documentation for the new drm_cmdline_mode
- Renamed overscan to tv_margins to be consistent with the APIs
Changes from v1:
- Dropped the patches to deal with EDID
- Added the unit test as selftest
- Rebased on next
Maxime Ripard (12):
drm/connector: Add documentation for drm_cmdline_mode
drm/client: Restrict the plane_state scope
drm/client: Restrict the rotation check to the rotation itself
drm/client: Change drm_client_panel_rotation name
drm/modes: Rewrite the command line parser
drm/modes: Support modes names on the command line
drm/modes: Allow to specify rotation and reflection on the commandline
drm/connector: Introduce a TV margins structure
drm/modes: Parse overscan properties
drm/atomic: Add a function to reset connector TV properties
drm/selftests: Add command line parser selftests
drm/vc4: hdmi: Set default state margin at reset
Documentation/fb/modedb.rst | 13 +-
drivers/gpu/drm/drm_atomic_state_helper.c | 18 +-
drivers/gpu/drm/drm_client_modeset.c | 54 +-
drivers/gpu/drm/drm_connector.c | 3 +-
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_modes.c | 473 +++++--
drivers/gpu/drm/selftests/Makefile | 2 +-
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 55 +-
drivers/gpu/drm/selftests/test-drm_cmdline_parser.c | 918 +++++++++++++-
drivers/gpu/drm/vc4/vc4_hdmi.c | 8 +-
include/drm/drm_atomic_state_helper.h | 1 +-
include/drm/drm_client.h | 2 +-
include/drm/drm_connector.h | 149 +-
13 files changed, 1557 insertions(+), 141 deletions(-)
create mode 100644 drivers/gpu/drm/selftests/drm_cmdline_selftests.h
create mode 100644 drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
base-commit: a125097c841039deef9dd589b86467f7d20f4b3d
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel^permalinkrawreply [flat|nested] 28+ messages in thread

*Re: [PATCH v5 06/12] drm/modes: Support modes names on the command line
2019-06-26 15:26 ` Thierry Reding@ 2019-06-28 13:43 ` Maxime Ripard0 siblings, 0 replies; 28+ messages in thread
From: Maxime Ripard @ 2019-06-28 13:43 UTC (permalink / raw)
To: Thierry Reding
Cc: eben, David Airlie, Maarten Lankhorst, dri-devel,
Paul Kocialkowski, Sean Paul, Thomas Petazzoni, Daniel Vetter,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 6252 bytes --]
Hi Thierry,
On Wed, Jun 26, 2019 at 05:26:59PM +0200, Thierry Reding wrote:
> On Mon, Jun 17, 2019 at 04:51:33PM +0200, Maxime Ripard wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > The drm subsystem also uses the video= kernel parameter, and in the
> > documentation refers to the fbdev documentation for that parameter.
> >
> > However, that documentation also says that instead of giving the mode using
> > its resolution we can also give a name. However, DRM doesn't handle that
> > case at the moment. Even though in most case it shouldn't make any
> > difference, it might be useful for analog modes, where different standards
> > might have the same resolution, but still have a few different parameters
> > that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example).
> >
> > Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/gpu/drm/drm_client_modeset.c | 4 ++-
> > drivers/gpu/drm/drm_connector.c | 3 +-
> > drivers/gpu/drm/drm_modes.c | 62 +++++++++++++++++++++--------
> > include/drm/drm_connector.h | 7 +++-
> > 4 files changed, 59 insertions(+), 17 deletions(-)
>
> This patch causes an issue on various Tegra boards that have so far been
> running flawlessly. Here's an extract from the boot log:
>
> [ 0.000000] Kernel command line: root=/dev/nfs rw netdevwait ip=:::::eth0:on nfsroot=192.168.23.1:/srv/nfs/tegra194 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.2.2 vpr=0x8000000@0xf0000000 sdhci_tegra.en_boot_part_access=1
> ...
> [ 18.597001] [drm:drm_connector_init [drm]] cmdline mode for connector DP-1 tegrafb 0x0@60Hz
> ...
> [ 18.627145] [drm:drm_connector_init [drm]] cmdline mode for connector DP-2 tegrafb 0x0@60Hz
> ...
> [ 18.673770] [drm:drm_connector_init [drm]] cmdline mode for connector HDMI-A-1 tegrafb 0x0@60Hz
> ...
> [ 19.057500] [drm:drm_mode_debug_printmodeline [drm]] Modeline "0x0": 0 0 0 0 0 0 0 1 4 1 0x20 0x6
> [ 19.066341] [drm:drm_mode_prune_invalid [drm]] Not using 0x0 mode: CLOCK_LOW
> ...
> [ 19.677803] [drm:drm_client_modeset_probe [drm]] looking for cmdline mode on connector 60
> [ 19.686019] [drm:drm_client_modeset_probe [drm]] found mode 0x0
> ...
> [ 19.851843] drm drm: failed to set initial configuration: -28
>
> So basically what's happening here is that the bootloader is passing a
> video= parameter on the command-line and after this patch, the DRM core
> will consider the tegrafb in that parameter to be a named video mode.
> The mode is then filtered out because it doesn't make any sense, but
> then drm_client_modeset_probe() still tries to use it, eventually
> leading to failure because we can't allocate memory for a 0x0
> framebuffer.
What was the behaviour before? That it wouldn't set a mode at all?
> Now, there are obviously a couple of places where things go wrong. On
> one hand I think if the mode specified on the command-line is already
> filtered out, then drm_client_modeset_probe() should not be trying to
> use it.
Yeah, that would make sense
> One could also argue that the bootloader shouldn't be passing that
> video=tegrafb parameter in the first place. Then again, this is nothing
> out of the ordinary (as documented in Documentation/fb/modedb.rst).
I've read that documentation, and I'm not sure which section in there
allows to do that?
> The problem with named modes, and you already highlighted this in your
> comment in the code, is that it's not possible to distinguish between a
> mode name and a video= option that defines the framebuffer device to
> use.
>
> That said, I wouldn't be surprised if this change ended up breaking on
> other devices. I'm also not sure that under these circumstances it's a
> good idea to support named modes. At least not until we have a better
> way of determining what's a real mode name and what isn't. Looking at
> the old modedb from fb, not even the standard modes listed there have
> names associated with them, so I'm not sure how this was ever supposed
> to work. From the looks of it, some of the fbdev drivers seem to take a
> mode list from board-code (see for example the mx21ads_modes array from
> arch/arm/mach-imx/mach-mx21ads.c). The imxfb driver can then take a mode
> name from the command line and try to match it against a list of known
> modes. That seems to match what the documentation says.
>
> However, that also really only works because this is all directly dealt
> with in the fbdev drivers. For DRM/KMS we don't do that and instead we
> rely on the core to provide this backwards-compatibility. However, at
> the time when we parse the mode from the command line we don't have the
> list of modes that are considered to be valid, so your patch currently
> needs to assume that it is a valid mode. I don't think that's a good
> idea, because clearly not all strings that currently make it through the
> filter are actually modes.
We have a list of named modes in the connector, and we match against
that. It already works for sunxi (minus the bugs..).
> So if we really need this, I think we want some way for the connector to
> provide the list of named modes that it supports so that by the time we
> want to parse the command-line we can check whether it's actually a name
> to avoid false positives like the ones I'm seeing on Tegra.
I guess that could work yep
> For now it might just be easiest to avoid any of this and disable the
> named mode support until it's a bit more mature. The patch no longer
> reverts cleanly, but it should be fairly easy to disable the feature in
> a follow-up patch again.
If we were to do that, I'd really like to have least get a unit test
for that case, and some documentation on how we're supposed to deal
with this case.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com[-- 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^permalinkrawreply [flat|nested] 28+ messages in thread

*Re: [v5,05/12] drm/modes: Rewrite the command line parser
2019-08-19 18:54 ` [v5,05/12] " Jernej Škrabec
@ 2019-08-19 19:20 ` Thomas Graichen
2019-08-20 15:00 ` Maxime Ripard0 siblings, 1 reply; 28+ messages in thread
From: Thomas Graichen @ 2019-08-19 19:20 UTC (permalink / raw)
To: Jernej Škrabec
Cc: eben, Maxime Ripard, Maarten Lankhorst, dri-devel,
Paul Kocialkowski, David Airlie, Sean Paul, Thomas Petazzoni,
Daniel Vetter, Maxime Ripard, linux-arm-kernel
On Mon, Aug 19, 2019 at 8:54 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> +CC: Thomas Graichen
>
> Dne ponedeljek, 17. junij 2019 ob 16:51:32 CEST je Maxime Ripard napisal(a):
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Rewrite the command line parser in order to get away from the state machine
> > parsing the video mode lines.
> >
> > Hopefully, this will allow to extend it more easily to support named modes
> > and / or properties set directly on the command line.
> >
> > Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Thomas reported to me that this patch breaks "video=CONNECTOR:e" kernel
> parameter which he currently uses as a workaround for H6 HDMI monitor
> detection issue on one STB.
>
> I suppose this is the same issue that Dmitry noticed.
>
> Thomas Graichen (in CC) can provide more information if needed.
>
> Best regards,
> Jernej
as jernej already mentioned i am currently having to use the kernel
cmdline option video=HDMI-A-1:e to get a working hdmi output on an
eachlink h6 mini tv box and was wondering that i did not get any hdmi
output even with this option when switching from the
https://github.com/megous/linux oprange-pi-5.2 to the orange-pi-5.3
branch which seems to contain this patch. as i had no idea what might
have caused the breakage of the hdmi output and did a full bisect of
the kernel between those two versions, which ended reliably at exactly
this patch - so i guess there is a regression at least with the
video=CONNECTOR:e option (maybe others too?) with this patches code
which makes it not working anymore.
best wishes - thomas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel^permalinkrawreply [flat|nested] 28+ messages in thread

*Re: [v5,05/12] drm/modes: Rewrite the command line parser
2019-08-19 19:20 ` Thomas Graichen@ 2019-08-20 15:00 ` Maxime Ripard
2019-08-23 14:04 ` Thomas Graichen0 siblings, 1 reply; 28+ messages in thread
From: Maxime Ripard @ 2019-08-20 15:00 UTC (permalink / raw)
To: Thomas Graichen
Cc: eben, David Airlie, Maarten Lankhorst, Jernej Škrabec,
Paul Kocialkowski, Sean Paul, dri-devel, Thomas Petazzoni,
Daniel Vetter, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2431 bytes --]
Hi,
On Mon, Aug 19, 2019 at 09:20:00PM +0200, Thomas Graichen wrote:
> On Mon, Aug 19, 2019 at 8:54 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > +CC: Thomas Graichen
> >
> > Dne ponedeljek, 17. junij 2019 ob 16:51:32 CEST je Maxime Ripard napisal(a):
> > > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> > >
> > > Rewrite the command line parser in order to get away from the state machine
> > > parsing the video mode lines.
> > >
> > > Hopefully, this will allow to extend it more easily to support named modes
> > > and / or properties set directly on the command line.
> > >
> > > Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Thomas reported to me that this patch breaks "video=CONNECTOR:e" kernel
> > parameter which he currently uses as a workaround for H6 HDMI monitor
> > detection issue on one STB.
> >
> > I suppose this is the same issue that Dmitry noticed.
> >
> > Thomas Graichen (in CC) can provide more information if needed.
>
> as jernej already mentioned i am currently having to use the kernel
> cmdline option video=HDMI-A-1:e to get a working hdmi output on an
> eachlink h6 mini tv box and was wondering that i did not get any hdmi
> output even with this option when switching from the
> https://github.com/megous/linux oprange-pi-5.2 to the orange-pi-5.3
> branch which seems to contain this patch.
Which kernel version is that based on?
> as i had no idea what might have caused the breakage of the hdmi
> output and did a full bisect of the kernel between those two
> versions, which ended reliably at exactly this patch - so i guess
> there is a regression at least with the video=CONNECTOR:e option
> (maybe others too?) with this patches code which makes it not
> working anymore.
I'm not sure I'll have the time to look into it this week (or the
next, unfortunately). However, the e parameter is supposed to be
parsed by drm_mode_parse_cmdline_extra, which in turn is supposed to
be called there:
https://elixir.bootlin.com/linux/v5.3-rc5/source/drivers/gpu/drm/drm_modes.c#L1810
If you can test that, having an idea of if that function is called,
which return code it returns, and if it isn't if why would be super
helpful.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com[-- 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^permalinkrawreply [flat|nested] 28+ messages in thread

*Re: [v5,05/12] drm/modes: Rewrite the command line parser
2019-08-20 15:00 ` Maxime Ripard@ 2019-08-23 14:04 ` Thomas Graichen0 siblings, 0 replies; 28+ messages in thread
From: Thomas Graichen @ 2019-08-23 14:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: eben, David Airlie, Maarten Lankhorst, Jernej Škrabec,
Paul Kocialkowski, Sean Paul, dri-devel, Thomas Petazzoni,
Daniel Vetter, linux-arm-kernel
hi maxim,
On Tue, Aug 20, 2019 at 5:00 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Mon, Aug 19, 2019 at 09:20:00PM +0200, Thomas Graichen wrote:
> > On Mon, Aug 19, 2019 at 8:54 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > >
> > > +CC: Thomas Graichen
> > >
> > > Dne ponedeljek, 17. junij 2019 ob 16:51:32 CEST je Maxime Ripard napisal(a):
> > > > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > >
> > > > Rewrite the command line parser in order to get away from the state machine
> > > > parsing the video mode lines.
> > > >
> > > > Hopefully, this will allow to extend it more easily to support named modes
> > > > and / or properties set directly on the command line.
> > > >
> > > > Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > >
> > > Thomas reported to me that this patch breaks "video=CONNECTOR:e" kernel
> > > parameter which he currently uses as a workaround for H6 HDMI monitor
> > > detection issue on one STB.
> > >
> > > I suppose this is the same issue that Dmitry noticed.
> > >
> > > Thomas Graichen (in CC) can provide more information if needed.
> >
> > as jernej already mentioned i am currently having to use the kernel
> > cmdline option video=HDMI-A-1:e to get a working hdmi output on an
> > eachlink h6 mini tv box and was wondering that i did not get any hdmi
> > output even with this option when switching from the
> > https://github.com/megous/linux oprange-pi-5.2 to the orange-pi-5.3
> > branch which seems to contain this patch.
>
> Which kernel version is that based on?
5.3-rc3
> > as i had no idea what might have caused the breakage of the hdmi
> > output and did a full bisect of the kernel between those two
> > versions, which ended reliably at exactly this patch - so i guess
> > there is a regression at least with the video=CONNECTOR:e option
> > (maybe others too?) with this patches code which makes it not
> > working anymore.
>
> I'm not sure I'll have the time to look into it this week (or the
> next, unfortunately). However, the e parameter is supposed to be
> parsed by drm_mode_parse_cmdline_extra, which in turn is supposed to
> be called there:
> https://elixir.bootlin.com/linux/v5.3-rc5/source/drivers/gpu/drm/drm_modes.c#L1810
>
> If you can test that, having an idea of if that function is called,
> which return code it returns, and if it isn't if why would be super
> helpful.
i just added a printk and it looks like it is not getting called:
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index b0369e690f36..4c58fdb1d7be 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1813,6 +1813,7 @@ bool
drm_mode_parse_command_line_for_connector(const char *mode_option,
ret = drm_mode_parse_cmdline_extra(extra_ptr, len,
connector, mode);
+ printk(KERN_WARNING "DEBUG -
drm_mode_parse_cmdline_extra %d", ret);
if (ret)
return false;
}
no output from it in dmesg (my loglevel=8 and on the kernel cmdline
and in /proc/cmdline i have "video=HDMI-A-1:e") - so looks like it
really gets lost somewhere along the way ...
best wishes - thomas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel^permalinkrawreply [flat|nested] 28+ messages in thread