Re: [PATCH 09/12] drm/modes: parse_cmdline: Add support for specifying panel_orientation

2019-11-11 Thread Hans de Goede

Hi,

On 11-11-2019 13:53, Maxime Ripard wrote:

Hi Hans,

Thanks for this series (and thanks for bouncing the mails too).

All the previous patches are
Acked-by: Maxime Ripard 


Thank you for the review.


On Sun, Nov 10, 2019 at 04:40:58PM +0100, Hans de Goede wrote:

Sometimes we want to override a connector's panel_orientation from the
kernel commandline. Either for testing and for special cases, e.g. a kiosk
like setup which uses a TV mounted in portrait mode.

Users can already specify a "rotate" option through a video= kernel cmdline
option. But that only supports 0/180 degrees (see drm_client_modeset TODO)
and only works for in kernel modeset clients, not for userspace kms users.

The "panel-orientation" connector property OTOH does support 90/270 degrees
as it leaves dealing with the rotation up to userspace and this does work
for userspace kms clients (at least those which support this property).

BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede 
---
  Documentation/fb/modedb.rst   |  3 ++
  drivers/gpu/drm/drm_modes.c   | 32 +++
  .../gpu/drm/selftests/drm_cmdline_selftests.h |  1 +
  .../drm/selftests/test-drm_cmdline_parser.c   | 22 +
  include/drm/drm_connector.h   |  8 +
  5 files changed, 66 insertions(+)

diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 9c4e3fd39e6d..624d08fd2856 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -65,6 +65,9 @@ Valid options are::
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
  degrees. Valid values are 0, 90, 180 and 270.
+  - panel_orientation, one of "normal", "upside_down", "left_side_up", or
+"right_side_up". For KMS drivers only, this sets the "panel orientation"
+property on the kms connector as hint for kms users.


Even though the semantic is a bit different, I think we should remain
consistent and have the same argument than for rotate (ie, steps in
clockwise rotation in steps of 90 degrees).


Well the kernel kms defines for rotation also talk about 90  / 180 / 270":

#define DRM_MODE_ROTATE_0   (1<<0)
#define DRM_MODE_ROTATE_90  (1<<1)
#define DRM_MODE_ROTATE_180 (1<<2)
#define DRM_MODE_ROTATE_270 (1<<3)

Where as the panel orientation uses strings like right_side_up, which means
that the side of the panel which normally is the right side of the panel
is now pointing up as the panel is mounted 90 degrees rotated with its
original right side now pointing up. This IMHO is much clearer then
90 / 270 degrees which are ambiguous and perhaps more importantly this
matches the kernel defines for panel-orientation and matches the
String values enumerated by the enum type panel-orientation connector
property:

static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
{ DRM_MODE_PANEL_ORIENTATION_LEFT_UP,   "Left Side Up"  },
{ DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,  "Right Side Up" },
};

So I would prefer to stick to the strings.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

2019-11-11 Thread Hans de Goede

Hi,

On 11-11-2019 16:40, Daniel Vetter wrote:

On Mon, Nov 11, 2019 at 12:06 PM Hans de Goede  wrote:


Hi Daniel,

On 11-11-2019 11:26, Daniel Vetter wrote:

On Mon, Nov 11, 2019 at 10:50 AM Hans de Goede  wrote:


Hi,

On 11-11-2019 10:25, Daniel Vetter wrote:

On Sun, Nov 10, 2019 at 7:41 PM Hans de Goede  wrote:


drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.

Signed-off-by: Hans de Goede 


Will existing userspace dtrt here with this? Some links to popular
ones would be good (since essentially this is uapi fine tuning we need
that anyway). With that will get my ack.


A valid question, I've gone over what I consider the major userspace kms users:
-Xorg xserver modesetting driver does not check for this:
[hans@shalem xserver]$ ack DRM_MODE_TYPE_ hw/xfree86/drivers/modesetting/
hw/xfree86/drivers/modesetting/drmmode_display.c
1321:if (kmode->type & DRM_MODE_TYPE_DRIVER)
1323:if (kmode->type & DRM_MODE_TYPE_PREFERRED)
-Other Xorg drivers:
[hans@shalem driver]$ ls -d xf86-video-*
xf86-video-amdgpu  xf86-video-intelxf86-video-qxl
xf86-video-armsoc  xf86-video-modesetting  xf86-video-sisusb
xf86-video-ati xf86-video-nouveau  xf86-video-vmware
xf86-video-dummy   xf86-video-omap xf86-video-voodoo
xf86-video-geode   xf86-video-opentegra
These all only do the same checks as the Xorg modesetting driver
-mutter:
[hans@shalem mutter]$ ack DRM_MODE_TYPE_
src/backends/native/meta-output-kms.c
261:  if (drm_mode->type & DRM_MODE_TYPE_PREFERRED)

So it seems nothing (that I can quickly find) in userspace is using this atm.

The reason I wrote this patch is because about a year ago plymouth used to
fully rely on the kernel to setup the modes on monitors and would simply
inherit the modes setup by the kernel. Basically plymouth was relying on
fbcon to load first and setup modes.

Deferred fbcon takeover (for flickerfree) means that this is no longer
happening. So now plymouth picks a mode itself. When I submitted the
plymouth change for plymouth to pick a mode itself the plymouth maintainer
(Ray Strode) was afraid that would break plymouth honoring video= arguments.
So currently plymouth still relies on the kernel to do the mode setup if
a video= argument is present on the kernel commandline.

My other recent series, which adds support for e.g.
video=HDMI:panel_orientation=right_side_up, made me realize that relying
on the kernel for this is no good since the fbcon code has various
limitations wrt e.g. hotplug and this of course will not work when
fbcon deferred takeover is used and fbcon never loads before plymouth.

So I wrote a patch for plymouth to check the DRM_MODE_TYPE_USERDEF
flag and prefer a mode with that flag over the PREFERRED mode:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/84

And then I found out that for that code to work with modes which
are already in the list of probed modes, I need something like
the kernel patch we are discussing now.

So if you want a link to an userspace consumer of this, I guess you
want a v2 with a link to the plymouth MR added. + maybe a blurb in
the commit message that to the best of my knowledge no userspace
kms consumers are checking for the DRM_MODE_TYPE_USERDEF flag?


And how does just relying on plymouth fix this?


The idea is to not automatically fix this, all I want to do is
provide enough info to userspace to make an informed decision,
plymouth honored the video= resolution, we want to
preserve that behavior.

Likewise historically and currently compositors / Xorg pretty
much ignore video=, I do not want to introduce changes on the
kernel side which unilateral force a change here. If compositors
want to start honoring a video= provided/selected mode then that
is up to them.


Given what you figured out in your quick search I think we should set
both USERDEF and PREFERRED, otherwise not much will happen here. Plus
I guess we need some fixup code to make sure that only the cmdline
mode is preferred, and no other mode? Except if all compositors pick
the first preferred mode consistently, then I guess we just need to
make sure it's first. Changing the meaning of USERDEF to also mean
"preferred mode, pls use that" could be fraught with peril, e.g. you
run a game on an old compositor (or with direct display) at lower
refresh, maybe with a custom mode, then it crashes. And from then on
all compositors insist on using your "pr

Re: [PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

2019-11-11 Thread Hans de Goede

Hi,

On 11-11-2019 15:11, Ville Syrjälä wrote:

On Mon, Nov 11, 2019 at 10:50:42AM +0100, Hans de Goede wrote:

Hi,

On 11-11-2019 10:25, Daniel Vetter wrote:

On Sun, Nov 10, 2019 at 7:41 PM Hans de Goede  wrote:


drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.

Signed-off-by: Hans de Goede 


Will existing userspace dtrt here with this? Some links to popular
ones would be good (since essentially this is uapi fine tuning we need
that anyway). With that will get my ack.


A valid question, I've gone over what I consider the major userspace kms users:
-Xorg xserver modesetting driver does not check for this:
   [hans@shalem xserver]$ ack DRM_MODE_TYPE_ hw/xfree86/drivers/modesetting/
   hw/xfree86/drivers/modesetting/drmmode_display.c
   1321:if (kmode->type & DRM_MODE_TYPE_DRIVER)
   1323:if (kmode->type & DRM_MODE_TYPE_PREFERRED)
-Other Xorg drivers:
   [hans@shalem driver]$ ls -d xf86-video-*
   xf86-video-amdgpu  xf86-video-intelxf86-video-qxl
   xf86-video-armsoc  xf86-video-modesetting  xf86-video-sisusb
   xf86-video-ati xf86-video-nouveau  xf86-video-vmware
   xf86-video-dummy   xf86-video-omap xf86-video-voodoo
   xf86-video-geode   xf86-video-opentegra
   These all only do the same checks as the Xorg modesetting driver
-mutter:
   [hans@shalem mutter]$ ack DRM_MODE_TYPE_
   src/backends/native/meta-output-kms.c
   261:  if (drm_mode->type & DRM_MODE_TYPE_PREFERRED)

So it seems nothing (that I can quickly find) in userspace is using this atm.

The reason I wrote this patch is because about a year ago plymouth used to
fully rely on the kernel to setup the modes on monitors and would simply
inherit the modes setup by the kernel. Basically plymouth was relying on
fbcon to load first and setup modes.

Deferred fbcon takeover (for flickerfree) means that this is no longer
happening. So now plymouth picks a mode itself. When I submitted the
plymouth change for plymouth to pick a mode itself the plymouth maintainer
(Ray Strode) was afraid that would break plymouth honoring video= arguments.
So currently plymouth still relies on the kernel to do the mode setup if
a video= argument is present on the kernel commandline.


Why can't plymouth just keep using the current mode if the crtc is
already active and otherwise pick a mode itself?


Well for one the firmware may have setup an output with a non
native mode because it always uses e.g 1024x768, we really want to
switch to the preferred mode in that case.

We could only pick the current mode if the crtc is already active
when video= is present on the kernel cmdline in an attempt to
honor video= arguments, but that will only work if fbcon has
already setup the modes according to the video= arguments and with
flickerfree boot we defer loading fbcon until there are kernel are initrd
errors to show. So in order to honor video= in a flickerfree setup
plymouth needs to pick the requested mode itself. Actually knowing which
mode is requested makes this a lot easier.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

2019-11-11 Thread Hans de Goede

Hi Daniel,

On 11-11-2019 11:26, Daniel Vetter wrote:

On Mon, Nov 11, 2019 at 10:50 AM Hans de Goede  wrote:


Hi,

On 11-11-2019 10:25, Daniel Vetter wrote:

On Sun, Nov 10, 2019 at 7:41 PM Hans de Goede  wrote:


drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.

Signed-off-by: Hans de Goede 


Will existing userspace dtrt here with this? Some links to popular
ones would be good (since essentially this is uapi fine tuning we need
that anyway). With that will get my ack.


A valid question, I've gone over what I consider the major userspace kms users:
-Xorg xserver modesetting driver does not check for this:
   [hans@shalem xserver]$ ack DRM_MODE_TYPE_ hw/xfree86/drivers/modesetting/
   hw/xfree86/drivers/modesetting/drmmode_display.c
   1321:if (kmode->type & DRM_MODE_TYPE_DRIVER)
   1323:if (kmode->type & DRM_MODE_TYPE_PREFERRED)
-Other Xorg drivers:
   [hans@shalem driver]$ ls -d xf86-video-*
   xf86-video-amdgpu  xf86-video-intelxf86-video-qxl
   xf86-video-armsoc  xf86-video-modesetting  xf86-video-sisusb
   xf86-video-ati xf86-video-nouveau  xf86-video-vmware
   xf86-video-dummy   xf86-video-omap xf86-video-voodoo
   xf86-video-geode   xf86-video-opentegra
   These all only do the same checks as the Xorg modesetting driver
-mutter:
   [hans@shalem mutter]$ ack DRM_MODE_TYPE_
   src/backends/native/meta-output-kms.c
   261:  if (drm_mode->type & DRM_MODE_TYPE_PREFERRED)

So it seems nothing (that I can quickly find) in userspace is using this atm.

The reason I wrote this patch is because about a year ago plymouth used to
fully rely on the kernel to setup the modes on monitors and would simply
inherit the modes setup by the kernel. Basically plymouth was relying on
fbcon to load first and setup modes.

Deferred fbcon takeover (for flickerfree) means that this is no longer
happening. So now plymouth picks a mode itself. When I submitted the
plymouth change for plymouth to pick a mode itself the plymouth maintainer
(Ray Strode) was afraid that would break plymouth honoring video= arguments.
So currently plymouth still relies on the kernel to do the mode setup if
a video= argument is present on the kernel commandline.

My other recent series, which adds support for e.g.
video=HDMI:panel_orientation=right_side_up, made me realize that relying
on the kernel for this is no good since the fbcon code has various
limitations wrt e.g. hotplug and this of course will not work when
fbcon deferred takeover is used and fbcon never loads before plymouth.

So I wrote a patch for plymouth to check the DRM_MODE_TYPE_USERDEF
flag and prefer a mode with that flag over the PREFERRED mode:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/84

And then I found out that for that code to work with modes which
are already in the list of probed modes, I need something like
the kernel patch we are discussing now.

So if you want a link to an userspace consumer of this, I guess you
want a v2 with a link to the plymouth MR added. + maybe a blurb in
the commit message that to the best of my knowledge no userspace
kms consumers are checking for the DRM_MODE_TYPE_USERDEF flag?


And how does just relying on plymouth fix this?


The idea is to not automatically fix this, all I want to do is
provide enough info to userspace to make an informed decision,
plymouth honored the video= resolution, we want to
preserve that behavior.

Likewise historically and currently compositors / Xorg pretty
much ignore video=, I do not want to introduce changes on the
kernel side which unilateral force a change here. If compositors
want to start honoring a video= provided/selected mode then that
is up to them.


Given what you figured out in your quick search I think we should set
both USERDEF and PREFERRED, otherwise not much will happen here. Plus
I guess we need some fixup code to make sure that only the cmdline
mode is preferred, and no other mode? Except if all compositors pick
the first preferred mode consistently, then I guess we just need to
make sure it's first. Changing the meaning of USERDEF to also mean
"preferred mode, pls use that" could be fraught with peril, e.g. you
run a game on an old compositor (or with direct display) at lower
refresh, maybe with a custom mode, then it crashes. And from then on
all compositors insist on using your "preferred" mode.


Right, I considered using PREFERRED instead (and clearing it on other
modes) and I delibera

Re: [PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

2019-11-11 Thread Hans de Goede

Hi,

On 11-11-2019 10:25, Daniel Vetter wrote:

On Sun, Nov 10, 2019 at 7:41 PM Hans de Goede  wrote:


drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.

Signed-off-by: Hans de Goede 


Will existing userspace dtrt here with this? Some links to popular
ones would be good (since essentially this is uapi fine tuning we need
that anyway). With that will get my ack.


A valid question, I've gone over what I consider the major userspace kms users:
-Xorg xserver modesetting driver does not check for this:
 [hans@shalem xserver]$ ack DRM_MODE_TYPE_ hw/xfree86/drivers/modesetting/
 hw/xfree86/drivers/modesetting/drmmode_display.c
 1321:if (kmode->type & DRM_MODE_TYPE_DRIVER)
 1323:if (kmode->type & DRM_MODE_TYPE_PREFERRED)
-Other Xorg drivers:
 [hans@shalem driver]$ ls -d xf86-video-*
 xf86-video-amdgpu  xf86-video-intelxf86-video-qxl
 xf86-video-armsoc  xf86-video-modesetting  xf86-video-sisusb
 xf86-video-ati xf86-video-nouveau  xf86-video-vmware
 xf86-video-dummy   xf86-video-omap xf86-video-voodoo
 xf86-video-geode   xf86-video-opentegra
 These all only do the same checks as the Xorg modesetting driver
-mutter:
 [hans@shalem mutter]$ ack DRM_MODE_TYPE_
 src/backends/native/meta-output-kms.c
 261:  if (drm_mode->type & DRM_MODE_TYPE_PREFERRED)

So it seems nothing (that I can quickly find) in userspace is using this atm.

The reason I wrote this patch is because about a year ago plymouth used to
fully rely on the kernel to setup the modes on monitors and would simply
inherit the modes setup by the kernel. Basically plymouth was relying on
fbcon to load first and setup modes.

Deferred fbcon takeover (for flickerfree) means that this is no longer
happening. So now plymouth picks a mode itself. When I submitted the
plymouth change for plymouth to pick a mode itself the plymouth maintainer
(Ray Strode) was afraid that would break plymouth honoring video= arguments.
So currently plymouth still relies on the kernel to do the mode setup if
a video= argument is present on the kernel commandline.

My other recent series, which adds support for e.g.
video=HDMI:panel_orientation=right_side_up, made me realize that relying
on the kernel for this is no good since the fbcon code has various
limitations wrt e.g. hotplug and this of course will not work when
fbcon deferred takeover is used and fbcon never loads before plymouth.

So I wrote a patch for plymouth to check the DRM_MODE_TYPE_USERDEF
flag and prefer a mode with that flag over the PREFERRED mode:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/84

And then I found out that for that code to work with modes which
are already in the list of probed modes, I need something like
the kernel patch we are discussing now.

So if you want a link to an userspace consumer of this, I guess you
want a v2 with a link to the plymouth MR added. + maybe a blurb in
the commit message that to the best of my knowledge no userspace
kms consumers are checking for the DRM_MODE_TYPE_USERDEF flag?

Regards,

Hans







-Danile


---
  drivers/gpu/drm/drm_probe_helper.c | 2 ++
  include/drm/drm_modes.h| 3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index ef2c468205a2..4fed64be11f9 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -157,6 +157,8 @@ static int drm_helper_probe_add_cmdline_mode(struct 
drm_connector *connector)
 continue;
 }

+   /* Mark the matching mode as being preferred by the user */
+   mode->type |= DRM_MODE_TYPE_USERDEF;
 return 0;
 }

diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index e946e20c61d8..c7efb7487e9b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -256,7 +256,8 @@ struct drm_display_mode {
  *  - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
  *them really. Drivers must set this bit for all modes they create
  *and expose to userspace.
-*  - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
+*  - DRM_MODE_TYPE_USERDEF: Mode defined or selected via the kernel
+*command line.
  *
  * Plus a big list of flags which shouldn't be used at all, but are
  * still around since these flags are also u

[PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

2019-11-10 Thread Hans de Goede
drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_probe_helper.c | 2 ++
 include/drm/drm_modes.h| 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index ef2c468205a2..4fed64be11f9 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -157,6 +157,8 @@ static int drm_helper_probe_add_cmdline_mode(struct 
drm_connector *connector)
continue;
}
 
+   /* Mark the matching mode as being preferred by the user */
+   mode->type |= DRM_MODE_TYPE_USERDEF;
return 0;
}
 
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index e946e20c61d8..c7efb7487e9b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -256,7 +256,8 @@ struct drm_display_mode {
 *  - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
 *them really. Drivers must set this bit for all modes they create
 *and expose to userspace.
-*  - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
+*  - DRM_MODE_TYPE_USERDEF: Mode defined or selected via the kernel
+*command line.
 *
 * Plus a big list of flags which shouldn't be used at all, but are
 * still around since these flags are also used in the userspace ABI.
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/12] drm/modes: parse_cmdline: Allow specifying stand-alone options

2019-11-10 Thread Hans de Goede
Some options which can be specified on the commandline, such as
margin_right=..., margin_left=..., etc. are applied not only to the
specified mode, but to all modes. As such it would be nice if the user
can simply say e.g.
video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42

This commit refactors drm_mode_parse_command_line_for_connector() to
add support for this, and as a nice side effect also cleans up the
function a bit.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c   | 92 +++
 .../gpu/drm/selftests/drm_cmdline_selftests.h |  2 +
 .../drm/selftests/test-drm_cmdline_parser.c   | 50 ++
 3 files changed, 86 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 72828fa9fc91..2e82603f5d0a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1677,17 +1677,6 @@ static const char * const drm_named_modes_whitelist[] = {
"PAL",
 };
 
-static bool drm_named_mode_is_in_whitelist(const char *mode, unsigned int size)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++)
-   if (!strncmp(mode, drm_named_modes_whitelist[i], size))
-   return true;
-
-   return false;
-}
-
 /**
  * drm_mode_parse_command_line_for_connector - parse command line modeline for 
connector
  * @mode_option: optional per connector mode option
@@ -1718,7 +1707,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
   struct drm_cmdline_mode *mode)
 {
const char *name;
-   bool named_mode = false, parse_extras = false;
+   bool freestanding = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
@@ -1738,49 +1727,14 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
name = mode_option;
 
-   /*
-* This is a bit convoluted. To differentiate between the
-* named modes and poorly formatted resolutions, we need a
-* bunch of things:
-*   - We need to make sure that the first character (which
-* would be our resolution in X) is a digit.
-*   - If not, then it's either a named mode or a force on/off.
-* To distinguish between the two, we need to run the
-* extra parsing function, and if not, then we consider it
-* a named mode.
-*
-* If this isn't enough, we should add more heuristics here,
-* and matching unit-tests.
-*/
-   if (!isdigit(name[0]) && name[0] != 'x') {
-   unsigned int namelen = strlen(name);
-
-   /*
-* Only the force on/off options can be in that case,
-* and they all take a single character.
-*/
-   if (namelen == 1) {
-   ret = drm_mode_parse_cmdline_extra(name, namelen, true,
-  connector, mode);
-   if (!ret)
-   return true;
-   }
-
-   named_mode = true;
-   }
-
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
 
refresh_ptr = strchr(name, '@');
-   if (refresh_ptr) {
-   if (named_mode)
-   return false;
-
+   if (refresh_ptr)
refresh_off = refresh_ptr - name;
-   }
 
/* Locate the start of named options */
options_ptr = strchr(name, ',');
@@ -1800,23 +1754,45 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
parse_extras = true;
}
 
-   if (named_mode) {
-   if (mode_end + 1 > DRM_DISPLAY_MODE_LEN)
-   return false;
+   /* First check for a named mode */
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+   if (ret == mode_end) {
+   if (refresh_ptr)
+   return false; /* named + refresh is invalid */
 
-   if (!drm_named_mode_is_in_whitelist(name, mode_end))
-   return false;
+   strcpy(mode->name, drm_named_modes_whitelist[i]);
+   mode->specified = true;
+   break;
+   }
+   }
 
-   strscpy(mode->name, name, mode_end + 1);
-   } else {
+   /* No named mode? Check for a normal mode argument, e.g. 1024x768 */
+   if (!mode->specified &am

[PATCH 06/12] drm/modes: parse_cmdline: Add freestanding argument to drm_mode_parse_cmdline_options()

2019-11-10 Thread Hans de Goede
Add a freestanding function argument to drm_mode_parse_cmdline_options()
similar to how drm_mode_parse_cmdline_extra() already has this.

This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 25e8edf4cfb8..80cb247c83c7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1592,6 +1592,7 @@ static int drm_mode_parse_cmdline_int(const char *delim, 
unsigned int *int_ret)
 }
 
 static int drm_mode_parse_cmdline_options(const char *str,
+ bool freestanding,
  const struct drm_connector *connector,
  struct drm_cmdline_mode *mode)
 {
@@ -1663,6 +1664,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
option = sep + 1;
} while (sep);
 
+   if (rotation && freestanding)
+   return -EINVAL;
+
mode->rotation_reflection = rotation;
 
return 0;
@@ -1855,6 +1859,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
 
if (options_ptr) {
ret = drm_mode_parse_cmdline_options(options_ptr + 1,
+false,
 connector, mode);
if (ret)
return false;
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/12] drm/connector: Hookup the new drm_cmdline_mode panel_orientation member

2019-11-10 Thread Hans de Goede
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.

BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_connector.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 40a985c411a6..591914f01cd4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -140,6 +140,13 @@ static void drm_connector_get_cmdline_mode(struct 
drm_connector *connector)
connector->force = mode->force;
}
 
+   if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
+   DRM_INFO("setting connector %s panel_orientation to %d\n",
+connector->name, mode->panel_orientation);
+   drm_connector_set_panel_orientation(connector,
+   mode->panel_orientation);
+   }
+
DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
  connector->name, mode->name,
  mode->xres, mode->yres,
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/12] drm/connector: Split out orientation quirk detection (v2)

2019-11-10 Thread Hans de Goede
From: Derek Basehore 

Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.

Hans de Goede (changes in v2):

Rename the function from drm_connector_init_panel_orientation_property
to drm_connector_set_panel_orientation[_with_quirk] and pass in the
panel-orientation to set.

Beside the rename, also make the function set the passed in value
only once, if the value was set before (to a value other then
DRM_MODE_PANEL_ORIENTATION_UNKNOWN) make any further set calls a no-op.

This change is preparation for allowing the user to override the
panel-orientation for any connector from the kernel commandline.
When the panel-orientation is overridden this way, then we must ignore
the panel-orientation detection done by the driver.

Signed-off-by: Derek Basehore 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_connector.c | 74 ++---
 drivers/gpu/drm/i915/display/icl_dsi.c  |  5 +-
 drivers/gpu/drm/i915/display/intel_dp.c |  9 ++-
 drivers/gpu/drm/i915/display/vlv_dsi.c  |  5 +-
 include/drm/drm_connector.h |  9 ++-
 5 files changed, 71 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..40a985c411a6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1114,7 +1114,8 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] 
= {
  * coordinates, so if userspace rotates the picture to adjust for
  * the orientation it must also apply the same transformation to the
  * touchscreen input coordinates. This property is initialized by calling
- * drm_connector_init_panel_orientation_property().
+ * drm_connector_set_panel_orientation() or
+ * drm_connector_set_panel_orientation_with_quirk()
  *
  * scaling mode:
  * This property defines how a non-native mode is upscaled to the native
@@ -1986,38 +1987,41 @@ void drm_connector_set_vrr_capable_property(
 EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
 
 /**
- * drm_connector_init_panel_orientation_property -
- * initialize the connecters panel_orientation property
- * @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
+ * drm_connector_set_panel_orientation - sets the connecter's panel_orientation
+ * @connector: connector for which to set the panel-orientation property.
+ * @panel_orientation: drm_panel_orientation value to set
+ *
+ * This function sets the connector's panel_orientation and attaches
+ * a "panel orientation" property to the connector.
  *
- * This function should only be called for built-in panels, after setting
- * connector->display_info.panel_orientation first (if known).
+ * Calling this function on a connector where the panel_orientation has
+ * already been set is a no-op (e.g. the orientation has been overridden with
+ * a kernel commandline option).
  *
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * It is allowed to call this function with a panel_orientation of
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN, in which case it is a no-op.
  *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int drm_connector_init_panel_orientation_property(
-   struct drm_connector *connector, int width, int height)
+int drm_connector_set_panel_orientation(
+   struct drm_connector *connector,
+   enum drm_panel_orientation panel_orientation)
 {
struct drm_device *dev = connector->dev;
struct drm_display_info *info = >display_info;
struct drm_property *prop;
-   int orientation_quirk;
 
-   orientation_quirk = drm_get_panel_orientation_quirk(width, height);
-   if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
-   info->panel_orientation = orientation_quirk;
+   /* Already set? */
+   if (info->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+   return 0;
 
-   if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+   /* Don't attach the property if the orientation is unknown */
+   if (panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
 
+   info->panel_orientation = panel_orientation;
+
prop = dev->mode_config.panel_orientation_property;
if (!prop) {
prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
@@ -2034,7 +2038,37 @@ int d

[PATCH 07/12] drm/modes: parse_cmdline: Set bpp/refresh_specified after successful parsing

2019-11-10 Thread Hans de Goede
drm_connector_get_cmdline_mode() calls
drm_mode_parse_command_line_for_connector() with >cmdline_mode
as mode argument, so anything which we store in the mode arguments gets
kept even if we return false.

Avoid storing a possibly false-postive bpp/refresh_specified setting
in connector->cmdline_mode by moving the setting of these to after
successful parsing of the bpp/refresh parts of the video= argument.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 80cb247c83c7..72828fa9fc91 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1771,10 +1771,8 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
-   if (bpp_ptr) {
+   if (bpp_ptr)
bpp_off = bpp_ptr - name;
-   mode->bpp_specified = true;
-   }
 
refresh_ptr = strchr(name, '@');
if (refresh_ptr) {
@@ -1782,7 +1780,6 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
return false;
 
refresh_off = refresh_ptr - name;
-   mode->refresh_specified = true;
}
 
/* Locate the start of named options */
@@ -1825,6 +1822,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
ret = drm_mode_parse_cmdline_bpp(bpp_ptr, _end_ptr, mode);
if (ret)
return false;
+
+   mode->bpp_specified = true;
}
 
if (refresh_ptr) {
@@ -1832,6 +1831,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
 _end_ptr, mode);
if (ret)
return false;
+
+   mode->refresh_specified = true;
}
 
/*
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/12] drm/modes: parse_cmdline: Rework drm_mode_parse_cmdline_options()

2019-11-10 Thread Hans de Goede
Refactor drm_mode_parse_cmdline_options() so that it takes a pointer
to the first option, rather then a pointer to the ',' before the first
option.

This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f49401124727..25e8edf4cfb8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,23 +1591,21 @@ static int drm_mode_parse_cmdline_int(const char 
*delim, unsigned int *int_ret)
return 0;
 }
 
-static int drm_mode_parse_cmdline_options(const char *str, size_t len,
+static int drm_mode_parse_cmdline_options(const char *str,
  const struct drm_connector *connector,
  struct drm_cmdline_mode *mode)
 {
unsigned int deg, margin, rotation = 0;
-   const char *sep = str;
+   const char *delim, *option, *sep;
 
-   while ((sep = strchr(sep, ','))) {
-   const char *delim, *option;
-
-   option = sep + 1;
+   option = str;
+   do {
delim = strchr(option, '=');
if (!delim) {
delim = strchr(option, ',');
 
if (!delim)
-   delim = str + len;
+   delim = option + strlen(option);
}
 
if (!strncmp(option, "rotate", delim - option)) {
@@ -1661,8 +1659,9 @@ static int drm_mode_parse_cmdline_options(const char 
*str, size_t len,
} else {
return -EINVAL;
}
-   sep = delim;
-   }
+   sep = strchr(delim, ',');
+   option = sep + 1;
+   } while (sep);
 
mode->rotation_reflection = rotation;
 
@@ -1855,9 +1854,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
}
 
if (options_ptr) {
-   int len = strlen(name) - (options_ptr - name);
-
-   ret = drm_mode_parse_cmdline_options(options_ptr, len,
+   ret = drm_mode_parse_cmdline_options(options_ptr + 1,
 connector, mode);
if (ret)
return false;
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/12] drm/modes: parse_cmdline: Remove some unnecessary code

2019-11-10 Thread Hans de Goede
Remove 2 bits of dead-code:

1) drm_mode_parse_command_line_for_connector() always gets called with a
zero-ed drm_cmdline_mode struct and assumes so in most places, so there is
no reason to set mode->specified to false if no mode_option is present.

2) fb_get_options() will return fb_mode_option if no video=
argument is present on the kernel commandline, so there is no need to also
do this in drm_mode_parse_command_line_for_connector() as our only caller
uses fb_get_options() to get the mode_option argument.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 119fed7ab815..0bf3cb8c08ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1747,15 +1747,8 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
 
-#ifdef CONFIG_FB
if (!mode_option)
-   mode_option = fb_mode_option;
-#endif
-
-   if (!mode_option) {
-   mode->specified = false;
return false;
-   }
 
name = mode_option;
 
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/12] drm/modes: parse_cmdline: Add support for specifying panel_orientation

2019-11-10 Thread Hans de Goede
Sometimes we want to override a connector's panel_orientation from the
kernel commandline. Either for testing and for special cases, e.g. a kiosk
like setup which uses a TV mounted in portrait mode.

Users can already specify a "rotate" option through a video= kernel cmdline
option. But that only supports 0/180 degrees (see drm_client_modeset TODO)
and only works for in kernel modeset clients, not for userspace kms users.

The "panel-orientation" connector property OTOH does support 90/270 degrees
as it leaves dealing with the rotation up to userspace and this does work
for userspace kms clients (at least those which support this property).

BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede 
---
 Documentation/fb/modedb.rst   |  3 ++
 drivers/gpu/drm/drm_modes.c   | 32 +++
 .../gpu/drm/selftests/drm_cmdline_selftests.h |  1 +
 .../drm/selftests/test-drm_cmdline_parser.c   | 22 +
 include/drm/drm_connector.h   |  8 +
 5 files changed, 66 insertions(+)

diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 9c4e3fd39e6d..624d08fd2856 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -65,6 +65,9 @@ Valid options are::
   - reflect_y (boolean): Perform an axial symmetry on the Y axis
   - rotate (integer): Rotate the initial framebuffer by x
 degrees. Valid values are 0, 90, 180 and 270.
+  - panel_orientation, one of "normal", "upside_down", "left_side_up", or
+"right_side_up". For KMS drivers only, this sets the "panel orientation"
+property on the kms connector as hint for kms users.
 
 
 -
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2e82603f5d0a..119fed7ab815 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,6 +1591,33 @@ static int drm_mode_parse_cmdline_int(const char *delim, 
unsigned int *int_ret)
return 0;
 }
 
+static int drm_mode_parse_panel_orientation(const char *delim,
+   struct drm_cmdline_mode *mode)
+{
+   const char *value;
+
+   if (*delim != '=')
+   return -EINVAL;
+
+   value = delim + 1;
+   delim = strchr(value, ',');
+   if (!delim)
+   delim = value + strlen(value);
+
+   if (!strncmp(value, "normal", delim - value))
+   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+   else if (!strncmp(value, "upside_down", delim - value))
+   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   else if (!strncmp(value, "left_side_up", delim - value))
+   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+   else if (!strncmp(value, "right_side_up", delim - value))
+   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
 static int drm_mode_parse_cmdline_options(const char *str,
  bool freestanding,
  const struct drm_connector *connector,
@@ -1657,6 +1684,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
return -EINVAL;
 
mode->tv_margins.bottom = margin;
+   } else if (!strncmp(option, "panel_orientation", delim - 
option)) {
+   if (drm_mode_parse_panel_orientation(delim, mode))
+   return -EINVAL;
} else {
return -EINVAL;
}
@@ -1715,6 +1745,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int i, len, ret;
 
+   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+
 #ifdef CONFIG_FB
if (!mode_option)
mode_option = fb_mode_option;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h 
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index aee92ac2cc21..ceac7af9a172 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -64,3 +64,4 @@ cmdline_test(drm_cmdline_test_bpp_extra_and_option)
 cmdline_test(drm_cmdline_test_extra_and_option)
 cmdline_test(drm_cmdline_test_freestanding_options)
 cmdline_test(drm_cmdline_test_freestanding_force_e_and_options)
+cmdline_test(drm_cmdline_test_panel_orientation)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c 
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 8248d4aa5aaa..520f3e66a384 100644
--- a/drive

[PATCH 00/12] drm/modes: parse_cmdline: Add support for specifying panel_orientation on the kernel cmdline

2019-11-10 Thread Hans de Goede
Hi All,

I've been thinking about adding support for overriding a connector's
panel-orientation from the kernel commandline from a while now. Both for
testing and for special cases, e.g. a kiosk like setup which uses a TV
mounted in portrait mode.

Then this plymouth merge-req came in:
"Force display orientation using configuration file"
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83

Which was the trigger for me to actually do this. This turned out to be
a bit more work then expected as I wanted users to be able to specify
the new "panel_orientation" option as a freestanding option, without
needing to prefix a resolution; and when working on that I stumbled over
various things which could be improved in the cmdline parsing code.

This patch-seet is the end result of all this. Amongst other tests,
it has been tested with the test-drm_cmdline_parser.ko selftest and it
adds some new tests to that in some of the patches.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/12] drm/modes: parse_cmdline: Fix possible reference past end of string

2019-11-10 Thread Hans de Goede
Before this commit, if the last option of a video=... option is for
example "rotate" without a "=" after it then delim will point to
the terminating 0 of the string, and value which is sets to 
will point one position past the end of the string.

This commit fixes this by enforcing that the contents of delim equals '='
as it should be for options which take a value, this check is done in a
new drm_mode_parse_cmdline_int helper function which factors out the
common integer parsing code for all the options which take an int.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 68 -
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 88232698d7a0..3c3c7435225f 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1568,11 +1568,34 @@ static int drm_mode_parse_cmdline_res_mode(const char 
*str, unsigned int length,
return 0;
 }
 
+static int drm_mode_parse_cmdline_int(const char *delim, unsigned int *int_ret)
+{
+   const char *value;
+   char *endp;
+
+   /*
+* delim must point to the '=', otherwise it is a syntax error and
+* if delim points to the terminating zero, then delim + 1 wil point
+* past the end of the string.
+*/
+   if (*delim != '=')
+   return -EINVAL;
+
+   value = delim + 1;
+   *int_ret = simple_strtol(value, , 10);
+
+   /* Make sure we have parsed something */
+   if (endp == value)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int drm_mode_parse_cmdline_options(char *str, size_t len,
  const struct drm_connector *connector,
  struct drm_cmdline_mode *mode)
 {
-   unsigned int rotation = 0;
+   unsigned int deg, margin, rotation = 0;
char *sep = str;
 
while ((sep = strchr(sep, ','))) {
@@ -1588,13 +1611,7 @@ static int drm_mode_parse_cmdline_options(char *str, 
size_t len,
}
 
if (!strncmp(option, "rotate", delim - option)) {
-   const char *value = delim + 1;
-   unsigned int deg;
-
-   deg = simple_strtol(value, , 10);
-
-   /* Make sure we have parsed something */
-   if (sep == value)
+   if (drm_mode_parse_cmdline_int(delim, ))
return -EINVAL;
 
switch (deg) {
@@ -1619,57 +1636,32 @@ static int drm_mode_parse_cmdline_options(char *str, 
size_t len,
}
} else if (!strncmp(option, "reflect_x", delim - option)) {
rotation |= DRM_MODE_REFLECT_X;
-   sep = delim;
} else if (!strncmp(option, "reflect_y", delim - option)) {
rotation |= DRM_MODE_REFLECT_Y;
-   sep = delim;
} else if (!strncmp(option, "margin_right", delim - option)) {
-   const char *value = delim + 1;
-   unsigned int margin;
-
-   margin = simple_strtol(value, , 10);
-
-   /* Make sure we have parsed something */
-   if (sep == value)
+   if (drm_mode_parse_cmdline_int(delim, ))
return -EINVAL;
 
mode->tv_margins.right = margin;
} else if (!strncmp(option, "margin_left", delim - option)) {
-   const char *value = delim + 1;
-   unsigned int margin;
-
-   margin = simple_strtol(value, , 10);
-
-   /* Make sure we have parsed something */
-   if (sep == value)
+   if (drm_mode_parse_cmdline_int(delim, ))
return -EINVAL;
 
mode->tv_margins.left = margin;
} else if (!strncmp(option, "margin_top", delim - option)) {
-   const char *value = delim + 1;
-   unsigned int margin;
-
-   margin = simple_strtol(value, , 10);
-
-   /* Make sure we have parsed something */
-   if (sep == value)
+   if (drm_mode_parse_cmdline_int(delim, ))
return -EINVAL;
 
mode->tv_margins.top = margin;
} else if (!strncmp(option, "margin_bottom", delim - option)) {
-   const char *value = delim + 1;
-   unsigned int margin;
-
-   margin = simple_strtol(value, , 10);
-
- 

[PATCH 04/12] drm/modes: parse_cmdline: Accept extras directly after mode combined with options

2019-11-10 Thread Hans de Goede
Before this commit it was impossible to combine an extra mode argument
specified directly after the resolution with an option, e.g.
video=HDMI-1:720x480e,rotate=180 would not work, either the "e" to force
enable would need to be dropped or the ",rotate=180", otherwise the
mode_option would not be accepted.

This commit fixes this by setting parse_extras to true in this case, so
that drm_mode_parse_cmdline_res_mode() parses the extra arguments directly
after the resolution.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c   |  1 +
 .../gpu/drm/selftests/drm_cmdline_selftests.h |  1 +
 .../drm/selftests/test-drm_cmdline_parser.c   | 24 +++
 3 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a8aa7955fd45..f49401124727 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1794,6 +1794,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
mode_end = refresh_off;
} else if (options_ptr) {
mode_end = options_off;
+   parse_extras = true;
} else {
mode_end = strlen(name);
parse_extras = true;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h 
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index ca1fc7a78953..003e2c3ffc39 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -61,3 +61,4 @@ cmdline_test(drm_cmdline_test_margin_options)
 cmdline_test(drm_cmdline_test_multiple_options)
 cmdline_test(drm_cmdline_test_invalid_option)
 cmdline_test(drm_cmdline_test_bpp_extra_and_option)
+cmdline_test(drm_cmdline_test_extra_and_option)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c 
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 5b8dea922257..bc4db017e993 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -1018,6 +1018,30 @@ static int drm_cmdline_test_bpp_extra_and_option(void 
*ignored)
return 0;
 }
 
+static int drm_cmdline_test_extra_and_option(void *ignored)
+{
+   struct drm_cmdline_mode mode = { };
+
+   
FAIL_ON(!drm_mode_parse_command_line_for_connector("720x480e,rotate=180",
+  _connector,
+  ));
+   FAIL_ON(!mode.specified);
+   FAIL_ON(mode.xres != 720);
+   FAIL_ON(mode.yres != 480);
+   FAIL_ON(mode.rotation_reflection != DRM_MODE_ROTATE_180);
+
+   FAIL_ON(mode.refresh_specified);
+   FAIL_ON(mode.bpp_specified);
+
+   FAIL_ON(mode.rb);
+   FAIL_ON(mode.cvt);
+   FAIL_ON(mode.interlace);
+   FAIL_ON(mode.margins);
+   FAIL_ON(mode.force != DRM_FORCE_ON);
+
+   return 0;
+}
+
 #include "drm_selftest.c"
 
 static int __init test_drm_cmdline_init(void)
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/12] drm/modes: parse_cmdline: Stop parsing extras after bpp / refresh at ', '

2019-11-10 Thread Hans de Goede
Before this commit it was impossible to add an extra mode argument after
a bpp or refresh specifier, combined with an option, e.g.
video=HDMI-1:720x480-24e,rotate=180 would not work, either the "e" to
force enable would need to be dropped or the ",rotate=180", otherwise
the mode_option would not be accepted.

This commit fixes this by fixing the length calculation if extras_ptr
is set to stop the extra parsing at the start of the options (stop at the
',' options_ptr points to).

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c   | 10 ---
 .../gpu/drm/selftests/drm_cmdline_selftests.h |  1 +
 .../drm/selftests/test-drm_cmdline_parser.c   | 26 +++
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 654d4b6fecb3..a8aa7955fd45 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1721,7 +1721,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
-   int ret;
+   int i, len, ret;
 
 #ifdef CONFIG_FB
if (!mode_option)
@@ -1841,9 +1841,11 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
else if (refresh_ptr)
extra_ptr = refresh_end_ptr;
 
-   if (extra_ptr &&
-   extra_ptr != options_ptr) {
-   int len = strlen(name) - (extra_ptr - name);
+   if (extra_ptr) {
+   if (options_ptr)
+   len = options_ptr - extra_ptr;
+   else
+   len = strlen(extra_ptr);
 
ret = drm_mode_parse_cmdline_extra(extra_ptr, len, false,
   connector, mode);
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h 
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index 6d61a0eb5d64..ca1fc7a78953 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -60,3 +60,4 @@ cmdline_test(drm_cmdline_test_vmirror)
 cmdline_test(drm_cmdline_test_margin_options)
 cmdline_test(drm_cmdline_test_multiple_options)
 cmdline_test(drm_cmdline_test_invalid_option)
+cmdline_test(drm_cmdline_test_bpp_extra_and_option)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c 
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 013de9d27c35..5b8dea922257 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -992,6 +992,32 @@ static int drm_cmdline_test_invalid_option(void *ignored)
return 0;
 }
 
+static int drm_cmdline_test_bpp_extra_and_option(void *ignored)
+{
+   struct drm_cmdline_mode mode = { };
+
+   
FAIL_ON(!drm_mode_parse_command_line_for_connector("720x480-24e,rotate=180",
+  _connector,
+  ));
+   FAIL_ON(!mode.specified);
+   FAIL_ON(mode.xres != 720);
+   FAIL_ON(mode.yres != 480);
+   FAIL_ON(mode.rotation_reflection != DRM_MODE_ROTATE_180);
+
+   FAIL_ON(mode.refresh_specified);
+
+   FAIL_ON(!mode.bpp_specified);
+   FAIL_ON(mode.bpp != 24);
+
+   FAIL_ON(mode.rb);
+   FAIL_ON(mode.cvt);
+   FAIL_ON(mode.interlace);
+   FAIL_ON(mode.margins);
+   FAIL_ON(mode.force != DRM_FORCE_ON);
+
+   return 0;
+}
+
 #include "drm_selftest.c"
 
 static int __init test_drm_cmdline_init(void)
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/12] drm/modes: parse_cmdline: Make various char pointers const

2019-11-10 Thread Hans de Goede
We are not supposed to modify the passed in string, make char pointers
used in drm_mode_parse_cmdline_options() const char * where possible.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3c3c7435225f..654d4b6fecb3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,15 +1591,15 @@ static int drm_mode_parse_cmdline_int(const char 
*delim, unsigned int *int_ret)
return 0;
 }
 
-static int drm_mode_parse_cmdline_options(char *str, size_t len,
+static int drm_mode_parse_cmdline_options(const char *str, size_t len,
  const struct drm_connector *connector,
  struct drm_cmdline_mode *mode)
 {
unsigned int deg, margin, rotation = 0;
-   char *sep = str;
+   const char *sep = str;
 
while ((sep = strchr(sep, ','))) {
-   char *delim, *option;
+   const char *delim, *option;
 
option = sep + 1;
delim = strchr(option, '=');
@@ -1718,8 +1718,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
bool named_mode = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
-   char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
-   char *options_ptr = NULL;
+   const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
+   const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int ret;
 
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vboxvideo: Use drm_gem_fb_create_with_dirty instead of drm_gem_fb_create

2019-10-29 Thread Hans de Goede

Hi,

On 28-10-2019 14:38, Thomas Zimmermann wrote:


Am 28.10.19 um 14:31 schrieb Hans de Goede:

Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer
with generic implemenation") removed the diy framebuffer code from
the vboxvideo driver, resulting in a nice cleanup.

But since the vboxvideo driver needs the generic dirty tracking code,
it's drm_mode_config_funcs.fb_create should be set to
drm_gem_fb_create_with_dirty not drm_gem_fb_create.

This commit fixes this, fixing the framebuffer not always updating.

Cc: Thomas Zimmermann 
Fixes: Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer with 
generic implemenation")
Signed-off-by: Hans de Goede 


Acked-by: Thomas Zimmermann 


Thanks, pushed to drm-misc-next

Regards,

Hans



---
  drivers/gpu/drm/vboxvideo/vbox_mode.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c 
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index d9818a8a32fa..f15ed2272205 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -838,7 +838,7 @@ static int vbox_connector_init(struct drm_device *dev,
  }
  
  static const struct drm_mode_config_funcs vbox_mode_funcs = {

-   .fb_create = drm_gem_fb_create,
+   .fb_create = drm_gem_fb_create_with_dirty,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
  };





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Program LUT before intel_color_commit() if LUT was not previously set v2

2019-10-28 Thread Hans de Goede
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.

The problem is that since this change, the LUT is programmed after the
write *and latching* of the double-buffered register which causes the LUT
to be used starting at the next frame. This means that the old LUT is still
used for the first couple of lines of the display. If no LUT was in use
before then the LUT registers may contain bogus values. This leads to
messed up colors until the new LUT values are written. At least on CHT DSI
panels this causes messed up colors on the first few lines.

This commit fixes this by adding a load_lut_before_commit boolean,
modifying commit_pipe_config() to load the luts earlier if this is set.
and setting this from intel_color_check when enabling gamma (rather then
updating an existing gamma table).

Changes in v2:
-Simply check for setting load_lut_before_commit to:
 if (!old_crtc_state->gamma_enable && new_crtc_state->gamma_enable)

Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank 
waits")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_color.c | 14 ++
 drivers/gpu/drm/i915/display/intel_display.c   |  6 +-
 drivers/gpu/drm/i915/display/intel_display_types.h |  3 +++
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index fa44eb73d088..954a232c15d1 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1063,6 +1063,8 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
intel_atomic_get_old_crtc_state(state, crtc);
struct intel_plane *plane;
 
+   new_crtc_state->load_lut_before_commit = false;
+
if (!new_crtc_state->base.active ||
drm_atomic_crtc_needs_modeset(_crtc_state->base))
return 0;
@@ -1071,6 +1073,18 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->csc_enable == old_crtc_state->csc_enable)
return 0;
 
+   /*
+* Normally we load the LUTs after vblank / after the double-buffer
+* registers written by commit have been latched, this avoids a
+* gamma change mid-way the screen. This does mean that the first
+* few lines of the display will (sometimes) still use the old
+* table. This is fine when changing an existing LUT, but if this
+* is the first time the LUT gets loaded, then the hw may contain
+* random values, causing the first lines to have funky colors.
+*/
+   if (!old_crtc_state->gamma_enable && new_crtc_state->gamma_enable)
+   new_crtc_state->load_lut_before_commit = true;
+
for_each_intel_plane_on_crtc(_priv->drm, crtc, plane) {
struct intel_plane_state *plane_state;
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index cbf9cf30050c..6b1dc5a5aeb1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14168,8 +14168,11 @@ static void commit_pipe_config(struct 
intel_atomic_state *state,
 */
if (!modeset) {
if (new_crtc_state->base.color_mgmt_changed ||
-   new_crtc_state->update_pipe)
+   new_crtc_state->update_pipe) {
+   if (new_crtc_state->load_lut_before_commit)
+   intel_color_load_luts(new_crtc_state);
intel_color_commit(new_crtc_state);
+   }
 
if (INTEL_GEN(dev_priv) >= 9)
skl_detach_scalers(new_crtc_state);
@@ -14717,6 +14720,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->base.active &&
!needs_modeset(new_crtc_state) &&
+   !new_crtc_state->load_lut_before_commit &&
(new_crtc_state->base.color_mgmt_changed ||
 new_crtc_state->update_pipe))
intel_color_load_luts(new_crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 40184e823c84..6bcc997b7ecb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -990,6 +990,9 @@ struct intel_crtc_state {
   

Re: [PATCH] drm/i915: Program LUT before intel_color_commit() if LUT was not previously set

2019-10-28 Thread Hans de Goede

Hi,

On 25-10-2019 21:45, Ville Syrjälä wrote:

On Fri, Oct 25, 2019 at 09:23:47PM +0200, Hans de Goede wrote:

Hi,

On 21-10-2019 16:39, Ville Syrjälä wrote:

On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:

Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.

The problem is that since this change, the LUT is programmed after the
write *and latching* of the double-buffered register which causes the LUT
to be used starting at the next frame. This means that the old LUT is still
used for the first couple of lines of the display. If no LUT was in use
before then the LUT registers may contain bogus values. This leads to
messed up colors until the new LUT values are written. At least on CHT DSI
panels this causes messed up colors on the first few lines.

This commit fixes this by adding a load_lut_before_commit boolean,
modifying intel_begin_crtc_commit to load the luts earlier if this is set,
and setting this from intel_color_check when a LUT table was not in use
before (and thus may contain bogus values), or when the table size
changes.


The real solution is vblank workers, which I have somewhat implemented
here:
git://github.com/vsyrjala/linux.git vblank_worker_8_kthread

Though even with the qos tricks there we still probably can't quite make
it in time. Essentially we have a bit less than one scanline after start
of vblank to do the work before pixels start to flow through the pipe.
We might be extend that to almost four scanlines but that partocular
thing is documeted as debug feature so not sure we should really use it.
Also I don't think four scanlines is always enough either. So it's still
very much possible that we get the first 100 or so pixels with the old LUT.


Thank you for the info and for the review.



Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank 
waits")
Signed-off-by: Hans de Goede 
---
   drivers/gpu/drm/i915/display/intel_color.c| 26 +++
   drivers/gpu/drm/i915/display/intel_display.c  |  7 +
   .../drm/i915/display/intel_display_types.h|  3 +++
   3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 71a0201437a9..0da6dcc5bebd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1052,6 +1052,32 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->update_planes |= BIT(plane->id);
}
   
+	/*

+* Normally we load the LUTs after vblank / after the double-buffer
+* registers written by commit have been latched, this avoids a
+* gamma change mid-way the screen. This does mean that the first
+* few lines of the display will (sometimes) still use the old
+* table. This is fine when changing an existing LUT, but if this
+* is the first time the LUT gets loaded, then the hw may contain
+* random values, causing the first lines to have funky colors.
+*
+* So if were enabling a LUT for the first time or changing the table
+* size, then we must do this before the commit to avoid corrupting
+* the first lines of the display.
+*/
+   if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (!old_crtc_state->base.degamma_lut &&
+new_crtc_state->base.degamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (old_crtc_state->base.gamma_lut &&
+new_crtc_state->base.gamma_lut &&
+lut_is_legacy(old_crtc_state->base.gamma_lut) !=
+   lut_is_legacy(new_crtc_state->base.gamma_lut))
+   new_crtc_state->load_lut_before_commit = true;
+   else
+   new_crtc_state->load_lut_before_commit = false;


The 'no gamma -> yes gamma' thing I might be willing to accept. The rest
not so much. I was already pondering about such optimizations for the
plane gamma/csc stuff in my vblank branch.


Ok, so I can submit a v2 based on dinq with only the
if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
check, or


But for the fastboot case I think what we could do is just sanitize
the LUT(s) after readout if gamma wasn't enabled by the BIOS.


We could do this, but this falls a bit outside of my expertise, I would be
more then happy to test a patch on one of the machines which needs this
LUTS sanitizing though. I get a very visible flash of a couple of bri

[PATCH] drm/vboxvideo: Use drm_gem_fb_create_with_dirty instead of drm_gem_fb_create

2019-10-28 Thread Hans de Goede
Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer
with generic implemenation") removed the diy framebuffer code from
the vboxvideo driver, resulting in a nice cleanup.

But since the vboxvideo driver needs the generic dirty tracking code,
it's drm_mode_config_funcs.fb_create should be set to
drm_gem_fb_create_with_dirty not drm_gem_fb_create.

This commit fixes this, fixing the framebuffer not always updating.

Cc: Thomas Zimmermann 
Fixes: Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer 
with generic implemenation")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/vboxvideo/vbox_mode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c 
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index d9818a8a32fa..f15ed2272205 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -838,7 +838,7 @@ static int vbox_connector_init(struct drm_device *dev,
 }
 
 static const struct drm_mode_config_funcs vbox_mode_funcs = {
-   .fb_create = drm_gem_fb_create,
+   .fb_create = drm_gem_fb_create_with_dirty,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/vboxvideo: Use generic fbdev and framebuffer

2019-10-28 Thread Hans de Goede

Hi,

On 28-10-2019 12:34, Thomas Zimmermann wrote:

Hi

Am 28.10.19 um 12:26 schrieb Hans de Goede:

Hi Thomas,

On 11-10-2019 15:48, Thomas Zimmermann wrote:

The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.

All patches have been tested on VirtualBox 6.0.12.

Thomas Zimmermann (3):
    drm/vboxvideo: Switch to generic fbdev emulation
    drm/vboxvideo: Switch to drm_atomic_helper_dirty_fb()
    drm/vboxvideo: Replace struct vram_framebuffer with generic
  implemenation


Thank you for these nice cleanups, unfortunately there is a small
bug in the last patch, you are setting:

 .fb_create = drm_gem_fb_create,

But since in the previous patch you switched to drm_atomic_helper_dirty_fb
that should be:

 .fb_create = drm_gem_fb_create_with_dirty,

The missing with_dirty is causing screenupdates under both plymouth and
gnome-shell (with llvmpipe) to gone missing. I'll send a patch fixing
this.


You're right. I did test the patchset, but I can't tell why I didn't see
this bug.


I know you tested the patch-set, since you said so above :)  You probably
are aware of this already, but did you check what vga-card the vm is using?
New vbox VMs default to their new vmware-svga card emulation, in which case
vboxvideo is not used at all, vboxvideo is only used with the older VboxVGA
and VboxSVGA (*) virtual vga-cards.


Anyway, thanks a lot for providing the fix.


You are welcome.

Regards,

Hans



*) Of course once I finally get their driver upstream they deprecate it, 
grumble.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/vboxvideo: Use generic fbdev and framebuffer

2019-10-28 Thread Hans de Goede

Hi Thomas,

On 11-10-2019 15:48, Thomas Zimmermann wrote:

The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.

All patches have been tested on VirtualBox 6.0.12.

Thomas Zimmermann (3):
   drm/vboxvideo: Switch to generic fbdev emulation
   drm/vboxvideo: Switch to drm_atomic_helper_dirty_fb()
   drm/vboxvideo: Replace struct vram_framebuffer with generic
 implemenation


Thank you for these nice cleanups, unfortunately there is a small
bug in the last patch, you are setting:

.fb_create = drm_gem_fb_create,

But since in the previous patch you switched to drm_atomic_helper_dirty_fb
that should be:

.fb_create = drm_gem_fb_create_with_dirty,

The missing with_dirty is causing screenupdates under both plymouth and
gnome-shell (with llvmpipe) to gone missing. I'll send a patch fixing
this.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Program LUT before intel_color_commit() if LUT was not previously set

2019-10-25 Thread Hans de Goede

Hi,

On 21-10-2019 16:39, Ville Syrjälä wrote:

On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:

Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.

The problem is that since this change, the LUT is programmed after the
write *and latching* of the double-buffered register which causes the LUT
to be used starting at the next frame. This means that the old LUT is still
used for the first couple of lines of the display. If no LUT was in use
before then the LUT registers may contain bogus values. This leads to
messed up colors until the new LUT values are written. At least on CHT DSI
panels this causes messed up colors on the first few lines.

This commit fixes this by adding a load_lut_before_commit boolean,
modifying intel_begin_crtc_commit to load the luts earlier if this is set,
and setting this from intel_color_check when a LUT table was not in use
before (and thus may contain bogus values), or when the table size
changes.


The real solution is vblank workers, which I have somewhat implemented
here:
git://github.com/vsyrjala/linux.git vblank_worker_8_kthread

Though even with the qos tricks there we still probably can't quite make
it in time. Essentially we have a bit less than one scanline after start
of vblank to do the work before pixels start to flow through the pipe.
We might be extend that to almost four scanlines but that partocular
thing is documeted as debug feature so not sure we should really use it.
Also I don't think four scanlines is always enough either. So it's still
very much possible that we get the first 100 or so pixels with the old LUT.


Thank you for the info and for the review.



Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank 
waits")
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/display/intel_color.c| 26 +++
  drivers/gpu/drm/i915/display/intel_display.c  |  7 +
  .../drm/i915/display/intel_display_types.h|  3 +++
  3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 71a0201437a9..0da6dcc5bebd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1052,6 +1052,32 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->update_planes |= BIT(plane->id);
}
  
+	/*

+* Normally we load the LUTs after vblank / after the double-buffer
+* registers written by commit have been latched, this avoids a
+* gamma change mid-way the screen. This does mean that the first
+* few lines of the display will (sometimes) still use the old
+* table. This is fine when changing an existing LUT, but if this
+* is the first time the LUT gets loaded, then the hw may contain
+* random values, causing the first lines to have funky colors.
+*
+* So if were enabling a LUT for the first time or changing the table
+* size, then we must do this before the commit to avoid corrupting
+* the first lines of the display.
+*/
+   if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (!old_crtc_state->base.degamma_lut &&
+new_crtc_state->base.degamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (old_crtc_state->base.gamma_lut &&
+new_crtc_state->base.gamma_lut &&
+lut_is_legacy(old_crtc_state->base.gamma_lut) !=
+   lut_is_legacy(new_crtc_state->base.gamma_lut))
+   new_crtc_state->load_lut_before_commit = true;
+   else
+   new_crtc_state->load_lut_before_commit = false;


The 'no gamma -> yes gamma' thing I might be willing to accept. The rest
not so much. I was already pondering about such optimizations for the
plane gamma/csc stuff in my vblank branch.


Ok, so I can submit a v2 based on dinq with only the
if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
check, or


But for the fastboot case I think what we could do is just sanitize
the LUT(s) after readout if gamma wasn't enabled by the BIOS.


We could do this, but this falls a bit outside of my expertise, I would be
more then happy to test a patch on one of the machines which needs this
LUTS sanitizing though. I get a very visible flash of a couple of bright
blue or yellow (2 different machines) on the upper few lines the first
time the gamma table gets loaded, so verifying

[PATCH v2 2/2] drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 hardware

2019-10-24 Thread Hans de Goede
We do not support atomic modesetting on pre-nv50 hardware, but until now
our connector code was setting drm_connector->state on pre-nv50 hardware.

This causes the core to enter atomic modesetting paths in at least:

1. drm_connector_get_encoder(), returning connector->state->best_encoder
which is always 0, causing us to always report 0 as encoder_id in
the drmModeConnector struct returned by drmModeGetConnector().

2. drm_encoder_get_crtc(), returning NULL because uses_atomic get set,
causing us to always report 0 as crtc_id in the drmModeEncoder struct
returned by drmModeGetEncoder()

Which in turn confuses userspace, at least plymouth thinks that the pipe
has changed because of this and tries to reconfigure it unnecessarily.

More in general we should not set drm_connector->state in the non-atomic
code as this violates the drm-core's expectations.

This commit fixes this by using a nouveau_conn_atom struct embedded in the
nouveau_connector struct for property handling in the non-atomic case.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1706557
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Fix trailing whitespace issue
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 28 +++--
 drivers/gpu/drm/nouveau/nouveau_connector.h |  6 +
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 94dfa2e5a9ab..805b341db165 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -245,14 +245,22 @@ nouveau_conn_atomic_duplicate_state(struct drm_connector 
*connector)
 void
 nouveau_conn_reset(struct drm_connector *connector)
 {
+   struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_conn_atom *asyc;
 
-   if (WARN_ON(!(asyc = kzalloc(sizeof(*asyc), GFP_KERNEL
-   return;
+   if (drm_drv_uses_atomic_modeset(connector->dev)) {
+   if (WARN_ON(!(asyc = kzalloc(sizeof(*asyc), GFP_KERNEL
+   return;
+
+   if (connector->state)
+   nouveau_conn_atomic_destroy_state(connector,
+ connector->state);
+
+   __drm_atomic_helper_connector_reset(connector, >state);
+   } else {
+   asyc = _connector->properties_state;
+   }
 
-   if (connector->state)
-   nouveau_conn_atomic_destroy_state(connector, connector->state);
-   __drm_atomic_helper_connector_reset(connector, >state);
asyc->dither.mode = DITHERING_MODE_AUTO;
asyc->dither.depth = DITHERING_DEPTH_AUTO;
asyc->scaler.mode = DRM_MODE_SCALE_NONE;
@@ -276,8 +284,14 @@ void
 nouveau_conn_attach_properties(struct drm_connector *connector)
 {
struct drm_device *dev = connector->dev;
-   struct nouveau_conn_atom *armc = nouveau_conn_atom(connector->state);
struct nouveau_display *disp = nouveau_display(dev);
+   struct nouveau_connector *nv_connector = nouveau_connector(connector);
+   struct nouveau_conn_atom *armc;
+
+   if (drm_drv_uses_atomic_modeset(connector->dev))
+   armc = nouveau_conn_atom(connector->state);
+   else
+   armc = _connector->properties_state;
 
/* Init DVI-I specific properties. */
if (connector->connector_type == DRM_MODE_CONNECTOR_DVII)
@@ -749,9 +763,9 @@ static int
 nouveau_connector_set_property(struct drm_connector *connector,
   struct drm_property *property, uint64_t value)
 {
-   struct nouveau_conn_atom *asyc = nouveau_conn_atom(connector->state);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
+   struct nouveau_conn_atom *asyc = _connector->properties_state;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
int ret;
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index de9588420884..de84fb4708c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -118,6 +118,12 @@ struct nouveau_connector {
 #ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
struct nouveau_backlight *backlight;
 #endif
+   /*
+* Our connector property code expects a nouveau_conn_atom struct
+* even on pre-nv50 where we do not support atomic. This embedded
+* version gets used in the non atomic modeset case.
+*/
+   struct nouveau_conn_atom properties_state;
 };
 
 static inline struct nouveau_connector *nouveau_connector(
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/nouveau: Move the declaration of struct nouveau_conn_atom up a bit

2019-10-24 Thread Hans de Goede
Place the declaration of struct nouveau_conn_atom above that of
struct nouveau_connector. This commit makes no changes to the moved
block what so ever, it just moves it up a bit.

This is a preparation patch to fix some issues with connector handling
on pre nv50 displays (which do not use atomic modesetting).

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_connector.h | 110 ++--
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index f43a8d63aef8..de9588420884 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -29,6 +29,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -44,6 +45,60 @@ struct dcb_output;
 struct nouveau_backlight;
 #endif
 
+#define nouveau_conn_atom(p)   
\
+   container_of((p), struct nouveau_conn_atom, state)
+
+struct nouveau_conn_atom {
+   struct drm_connector_state state;
+
+   struct {
+   /* The enum values specifically defined here match nv50/gf119
+* hw values, and the code relies on this.
+*/
+   enum {
+   DITHERING_MODE_OFF = 0x00,
+   DITHERING_MODE_ON = 0x01,
+   DITHERING_MODE_DYNAMIC2X2 = 0x10 | DITHERING_MODE_ON,
+   DITHERING_MODE_STATIC2X2 = 0x18 | DITHERING_MODE_ON,
+   DITHERING_MODE_TEMPORAL = 0x20 | DITHERING_MODE_ON,
+   DITHERING_MODE_AUTO
+   } mode;
+   enum {
+   DITHERING_DEPTH_6BPC = 0x00,
+   DITHERING_DEPTH_8BPC = 0x02,
+   DITHERING_DEPTH_AUTO
+   } depth;
+   } dither;
+
+   struct {
+   int mode;   /* DRM_MODE_SCALE_* */
+   struct {
+   enum {
+   UNDERSCAN_OFF,
+   UNDERSCAN_ON,
+   UNDERSCAN_AUTO,
+   } mode;
+   u32 hborder;
+   u32 vborder;
+   } underscan;
+   bool full;
+   } scaler;
+
+   struct {
+   int color_vibrance;
+   int vibrant_hue;
+   } procamp;
+
+   union {
+   struct {
+   bool dither:1;
+   bool scaler:1;
+   bool procamp:1;
+   };
+   u8 mask;
+   } set;
+};
+
 struct nouveau_connector {
struct drm_connector base;
enum dcb_connector_type type;
@@ -121,61 +176,6 @@ extern int nouveau_ignorelid;
 extern int nouveau_duallink;
 extern int nouveau_hdmimhz;
 
-#include 
-#define nouveau_conn_atom(p)   
\
-   container_of((p), struct nouveau_conn_atom, state)
-
-struct nouveau_conn_atom {
-   struct drm_connector_state state;
-
-   struct {
-   /* The enum values specifically defined here match nv50/gf119
-* hw values, and the code relies on this.
-*/
-   enum {
-   DITHERING_MODE_OFF = 0x00,
-   DITHERING_MODE_ON = 0x01,
-   DITHERING_MODE_DYNAMIC2X2 = 0x10 | DITHERING_MODE_ON,
-   DITHERING_MODE_STATIC2X2 = 0x18 | DITHERING_MODE_ON,
-   DITHERING_MODE_TEMPORAL = 0x20 | DITHERING_MODE_ON,
-   DITHERING_MODE_AUTO
-   } mode;
-   enum {
-   DITHERING_DEPTH_6BPC = 0x00,
-   DITHERING_DEPTH_8BPC = 0x02,
-   DITHERING_DEPTH_AUTO
-   } depth;
-   } dither;
-
-   struct {
-   int mode;   /* DRM_MODE_SCALE_* */
-   struct {
-   enum {
-   UNDERSCAN_OFF,
-   UNDERSCAN_ON,
-   UNDERSCAN_AUTO,
-   } mode;
-   u32 hborder;
-   u32 vborder;
-   } underscan;
-   bool full;
-   } scaler;
-
-   struct {
-   int color_vibrance;
-   int vibrant_hue;
-   } procamp;
-
-   union {
-   struct {
-   bool dither:1;
-   bool scaler:1;
-   bool procamp:1;
-   };
-   u8 mask;
-   } set;
-};
-
 void nouveau_conn_attach_properties(struct drm_connector *);
 void nouveau_conn_reset(struct drm_connector *);
 struct drm_connector_state *
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https

[PATCH 1/2] drm/nouveau: Move the declaration of struct nouveau_conn_atom up a bit

2019-10-23 Thread Hans de Goede
Place the declaration of struct nouveau_conn_atom above that of
struct nouveau_connector. This commit makes no changes to the moved
block what so ever, it just moves it up a bit.

This is a preparation patch to fix some issues with connector handling
on pre nv50 displays (which do not use atomic modesetting).

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_connector.h | 110 ++--
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index f43a8d63aef8..de9588420884 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -29,6 +29,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -44,6 +45,60 @@ struct dcb_output;
 struct nouveau_backlight;
 #endif
 
+#define nouveau_conn_atom(p)   
\
+   container_of((p), struct nouveau_conn_atom, state)
+
+struct nouveau_conn_atom {
+   struct drm_connector_state state;
+
+   struct {
+   /* The enum values specifically defined here match nv50/gf119
+* hw values, and the code relies on this.
+*/
+   enum {
+   DITHERING_MODE_OFF = 0x00,
+   DITHERING_MODE_ON = 0x01,
+   DITHERING_MODE_DYNAMIC2X2 = 0x10 | DITHERING_MODE_ON,
+   DITHERING_MODE_STATIC2X2 = 0x18 | DITHERING_MODE_ON,
+   DITHERING_MODE_TEMPORAL = 0x20 | DITHERING_MODE_ON,
+   DITHERING_MODE_AUTO
+   } mode;
+   enum {
+   DITHERING_DEPTH_6BPC = 0x00,
+   DITHERING_DEPTH_8BPC = 0x02,
+   DITHERING_DEPTH_AUTO
+   } depth;
+   } dither;
+
+   struct {
+   int mode;   /* DRM_MODE_SCALE_* */
+   struct {
+   enum {
+   UNDERSCAN_OFF,
+   UNDERSCAN_ON,
+   UNDERSCAN_AUTO,
+   } mode;
+   u32 hborder;
+   u32 vborder;
+   } underscan;
+   bool full;
+   } scaler;
+
+   struct {
+   int color_vibrance;
+   int vibrant_hue;
+   } procamp;
+
+   union {
+   struct {
+   bool dither:1;
+   bool scaler:1;
+   bool procamp:1;
+   };
+   u8 mask;
+   } set;
+};
+
 struct nouveau_connector {
struct drm_connector base;
enum dcb_connector_type type;
@@ -121,61 +176,6 @@ extern int nouveau_ignorelid;
 extern int nouveau_duallink;
 extern int nouveau_hdmimhz;
 
-#include 
-#define nouveau_conn_atom(p)   
\
-   container_of((p), struct nouveau_conn_atom, state)
-
-struct nouveau_conn_atom {
-   struct drm_connector_state state;
-
-   struct {
-   /* The enum values specifically defined here match nv50/gf119
-* hw values, and the code relies on this.
-*/
-   enum {
-   DITHERING_MODE_OFF = 0x00,
-   DITHERING_MODE_ON = 0x01,
-   DITHERING_MODE_DYNAMIC2X2 = 0x10 | DITHERING_MODE_ON,
-   DITHERING_MODE_STATIC2X2 = 0x18 | DITHERING_MODE_ON,
-   DITHERING_MODE_TEMPORAL = 0x20 | DITHERING_MODE_ON,
-   DITHERING_MODE_AUTO
-   } mode;
-   enum {
-   DITHERING_DEPTH_6BPC = 0x00,
-   DITHERING_DEPTH_8BPC = 0x02,
-   DITHERING_DEPTH_AUTO
-   } depth;
-   } dither;
-
-   struct {
-   int mode;   /* DRM_MODE_SCALE_* */
-   struct {
-   enum {
-   UNDERSCAN_OFF,
-   UNDERSCAN_ON,
-   UNDERSCAN_AUTO,
-   } mode;
-   u32 hborder;
-   u32 vborder;
-   } underscan;
-   bool full;
-   } scaler;
-
-   struct {
-   int color_vibrance;
-   int vibrant_hue;
-   } procamp;
-
-   union {
-   struct {
-   bool dither:1;
-   bool scaler:1;
-   bool procamp:1;
-   };
-   u8 mask;
-   } set;
-};
-
 void nouveau_conn_attach_properties(struct drm_connector *);
 void nouveau_conn_reset(struct drm_connector *);
 struct drm_connector_state *
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https

[PATCH 2/2] drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 hardware

2019-10-23 Thread Hans de Goede
We do not support atomic modesetting on pre-nv50 hardware, but until now
our connector code was setting drm_connector->state on pre-nv50 hardware.

This causes the core to enter atomic modesetting paths in at least:

1. drm_connector_get_encoder(), returning connector->state->best_encoder
which is always 0, causing us to always report 0 as encoder_id in
the drmModeConnector struct returned by drmModeGetConnector().

2. drm_encoder_get_crtc(), returning NULL because uses_atomic get set,
causing us to always report 0 as crtc_id in the drmModeEncoder struct
returned by drmModeGetEncoder()

Which in turn confuses userspace, at least plymouth thinks that the pipe
has changed because of this and tries to reconfigure it unnecessarily.

More in general we should not set drm_connector->state in the non-atomic
code as this violates the drm-core's expectations.

This commit fixes this by using a nouveau_conn_atom struct embedded in the
nouveau_connector struct for property handling in the non-atomic case.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1706557
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 28 +++--
 drivers/gpu/drm/nouveau/nouveau_connector.h |  6 +
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 94dfa2e5a9ab..805b341db165 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -245,14 +245,22 @@ nouveau_conn_atomic_duplicate_state(struct drm_connector 
*connector)
 void
 nouveau_conn_reset(struct drm_connector *connector)
 {
+   struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_conn_atom *asyc;
 
-   if (WARN_ON(!(asyc = kzalloc(sizeof(*asyc), GFP_KERNEL
-   return;
+   if (drm_drv_uses_atomic_modeset(connector->dev)) {
+   if (WARN_ON(!(asyc = kzalloc(sizeof(*asyc), GFP_KERNEL
+   return;
+
+   if (connector->state)
+   nouveau_conn_atomic_destroy_state(connector,
+ connector->state);
+
+   __drm_atomic_helper_connector_reset(connector, >state);
+   } else {
+   asyc = _connector->properties_state;
+   }
 
-   if (connector->state)
-   nouveau_conn_atomic_destroy_state(connector, connector->state);
-   __drm_atomic_helper_connector_reset(connector, >state);
asyc->dither.mode = DITHERING_MODE_AUTO;
asyc->dither.depth = DITHERING_DEPTH_AUTO;
asyc->scaler.mode = DRM_MODE_SCALE_NONE;
@@ -276,8 +284,14 @@ void
 nouveau_conn_attach_properties(struct drm_connector *connector)
 {
struct drm_device *dev = connector->dev;
-   struct nouveau_conn_atom *armc = nouveau_conn_atom(connector->state);
struct nouveau_display *disp = nouveau_display(dev);
+   struct nouveau_connector *nv_connector = nouveau_connector(connector);
+   struct nouveau_conn_atom *armc;
+
+   if (drm_drv_uses_atomic_modeset(connector->dev))
+   armc = nouveau_conn_atom(connector->state);
+   else
+   armc = _connector->properties_state;
 
/* Init DVI-I specific properties. */
if (connector->connector_type == DRM_MODE_CONNECTOR_DVII)
@@ -749,9 +763,9 @@ static int
 nouveau_connector_set_property(struct drm_connector *connector,
   struct drm_property *property, uint64_t value)
 {
-   struct nouveau_conn_atom *asyc = nouveau_conn_atom(connector->state);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
+   struct nouveau_conn_atom *asyc = _connector->properties_state;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
int ret;
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index de9588420884..2d70dea4018b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -118,6 +118,12 @@ struct nouveau_connector {
 #ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
struct nouveau_backlight *backlight;
 #endif
+   /*
+* Our connector property code expects a nouveau_conn_atom struct
+* even on pre-nv50 where we do not support atomic. This embedded
+* version gets used in the non atomic modeset case.
+*/ 
+   struct nouveau_conn_atom properties_state;
 };
 
 static inline struct nouveau_connector *nouveau_connector(
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Program LUT before intel_color_commit() if LUT was not previously set

2019-10-21 Thread Hans de Goede

Hi,

On 20-10-2019 20:19, Hans de Goede wrote:

Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.

The problem is that since this change, the LUT is programmed after the
write *and latching* of the double-buffered register which causes the LUT
to be used starting at the next frame. This means that the old LUT is still
used for the first couple of lines of the display. If no LUT was in use
before then the LUT registers may contain bogus values. This leads to
messed up colors until the new LUT values are written. At least on CHT DSI
panels this causes messed up colors on the first few lines.

This commit fixes this by adding a load_lut_before_commit boolean,
modifying intel_begin_crtc_commit to load the luts earlier if this is set,
and setting this from intel_color_check when a LUT table was not in use
before (and thus may contain bogus values), or when the table size
changes.

Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank 
waits")
Signed-off-by: Hans de Goede 


So this failed to apply in CI, I based this on 5.4 and I clearly need to rebase
it on top of dinq. Before I do this I would appreciate a review though, as I'm
not entirely sure that this is the right approach to fixing the issue.

Regards,

Hans




---
  drivers/gpu/drm/i915/display/intel_color.c| 26 +++
  drivers/gpu/drm/i915/display/intel_display.c  |  7 +
  .../drm/i915/display/intel_display_types.h|  3 +++
  3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 71a0201437a9..0da6dcc5bebd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1052,6 +1052,32 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->update_planes |= BIT(plane->id);
}
  
+	/*

+* Normally we load the LUTs after vblank / after the double-buffer
+* registers written by commit have been latched, this avoids a
+* gamma change mid-way the screen. This does mean that the first
+* few lines of the display will (sometimes) still use the old
+* table. This is fine when changing an existing LUT, but if this
+* is the first time the LUT gets loaded, then the hw may contain
+* random values, causing the first lines to have funky colors.
+*
+* So if were enabling a LUT for the first time or changing the table
+* size, then we must do this before the commit to avoid corrupting
+* the first lines of the display.
+*/
+   if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (!old_crtc_state->base.degamma_lut &&
+new_crtc_state->base.degamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (old_crtc_state->base.gamma_lut &&
+new_crtc_state->base.gamma_lut &&
+lut_is_legacy(old_crtc_state->base.gamma_lut) !=
+   lut_is_legacy(new_crtc_state->base.gamma_lut))
+   new_crtc_state->load_lut_before_commit = true;
+   else
+   new_crtc_state->load_lut_before_commit = false;
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c

index aa54bb22796d..21442b0dd134 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14033,6 +14033,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->base.active &&
!needs_modeset(new_crtc_state) &&
+   !new_crtc_state->load_lut_before_commit &&
(new_crtc_state->base.color_mgmt_changed ||
 new_crtc_state->update_pipe))
intel_color_load_luts(new_crtc_state);
@@ -14529,6 +14530,12 @@ static void intel_begin_crtc_commit(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
bool modeset = needs_modeset(new_crtc_state);
  
+	if (!modeset &&

+   new_crtc_state->load_lut_before_commit &&
+   (new_crtc_state->base.color_mgmt_changed ||
+new_crtc_state->update_pipe))
+   intel_color_load_luts(new_crtc_state);
+
/* Perform vblank evasi

[PATCH] drm/i915: Try to re-use GOP / previous M-N-P settings for vlv DSI PLL

2019-10-20 Thread Hans de Goede
Fastboot is not working on an Asus T100HA, it gives the following
relevant messages / errors:

 dsi pll div 000201e6, ctrl 80080100
 fastset mismatch in dsi_pll.ctrl (expected 0x80100100, found 0x80080100)
 fastset mismatch in dsi_pll.div (expected 0x0002008e, found 0x000201e6)

The problem seems to be that the GOP picks 5 for the P divisor, where as
we end up picking 4.

This commit fixes this by first checking of the currently configured
DSI PLL settings match the desired pclk and if they do, stick with
the currently configured PLL settings.

Note that vlv_dsi_get_pclk() stores the read ctrl and div values inside
config->dsi_pll, so they are set to the GOP / previous values after
calling it.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 26 +++---
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c 
b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
index 95f39cd0ce02..4a09edecd597 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
@@ -119,15 +119,25 @@ int vlv_dsi_pll_compute(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
int ret;
-   u32 dsi_clk;
-
-   dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
-   intel_dsi->lane_count);
+   u32 dsi_clk, current_pclk;
 
-   ret = dsi_calc_mnp(dev_priv, config, dsi_clk);
-   if (ret) {
-   DRM_DEBUG_KMS("dsi_calc_mnp failed\n");
-   return ret;
+   /*
+* For exact matches, the GOP may pick another set of divisors
+* then we do, if the GOP settings are an exact match keep them.
+*/
+   current_pclk = vlv_dsi_get_pclk(encoder, config);
+   if (current_pclk == intel_dsi->pclk) {
+   config->dsi_pll.ctrl &= DSI_PLL_P1_POST_DIV_MASK;
+   } else {
+   dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk,
+   intel_dsi->pixel_format,
+   intel_dsi->lane_count);
+
+   ret = dsi_calc_mnp(dev_priv, config, dsi_clk);
+   if (ret) {
+   DRM_DEBUG_KMS("dsi_calc_mnp failed\n");
+   return ret;
+   }
}
 
if (intel_dsi->ports & (1 << PORT_A))
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Program LUT before intel_color_commit() if LUT was not previously set

2019-10-20 Thread Hans de Goede
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.

The problem is that since this change, the LUT is programmed after the
write *and latching* of the double-buffered register which causes the LUT
to be used starting at the next frame. This means that the old LUT is still
used for the first couple of lines of the display. If no LUT was in use
before then the LUT registers may contain bogus values. This leads to
messed up colors until the new LUT values are written. At least on CHT DSI
panels this causes messed up colors on the first few lines.

This commit fixes this by adding a load_lut_before_commit boolean,
modifying intel_begin_crtc_commit to load the luts earlier if this is set,
and setting this from intel_color_check when a LUT table was not in use
before (and thus may contain bogus values), or when the table size
changes.

Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank 
waits")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_color.c| 26 +++
 drivers/gpu/drm/i915/display/intel_display.c  |  7 +
 .../drm/i915/display/intel_display_types.h|  3 +++
 3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 71a0201437a9..0da6dcc5bebd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1052,6 +1052,32 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->update_planes |= BIT(plane->id);
}
 
+   /*
+* Normally we load the LUTs after vblank / after the double-buffer
+* registers written by commit have been latched, this avoids a
+* gamma change mid-way the screen. This does mean that the first
+* few lines of the display will (sometimes) still use the old
+* table. This is fine when changing an existing LUT, but if this
+* is the first time the LUT gets loaded, then the hw may contain
+* random values, causing the first lines to have funky colors.
+*
+* So if were enabling a LUT for the first time or changing the table
+* size, then we must do this before the commit to avoid corrupting
+* the first lines of the display.
+*/
+   if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (!old_crtc_state->base.degamma_lut &&
+new_crtc_state->base.degamma_lut)
+   new_crtc_state->load_lut_before_commit = true;
+   else if (old_crtc_state->base.gamma_lut &&
+new_crtc_state->base.gamma_lut &&
+lut_is_legacy(old_crtc_state->base.gamma_lut) !=
+   lut_is_legacy(new_crtc_state->base.gamma_lut))
+   new_crtc_state->load_lut_before_commit = true;
+   else
+   new_crtc_state->load_lut_before_commit = false;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index aa54bb22796d..21442b0dd134 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14033,6 +14033,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->base.active &&
!needs_modeset(new_crtc_state) &&
+   !new_crtc_state->load_lut_before_commit &&
(new_crtc_state->base.color_mgmt_changed ||
 new_crtc_state->update_pipe))
intel_color_load_luts(new_crtc_state);
@@ -14529,6 +14530,12 @@ static void intel_begin_crtc_commit(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
bool modeset = needs_modeset(new_crtc_state);
 
+   if (!modeset &&
+   new_crtc_state->load_lut_before_commit &&
+   (new_crtc_state->base.color_mgmt_changed ||
+new_crtc_state->update_pipe))
+   intel_color_load_luts(new_crtc_state);
+
/* Perform vblank evasion around commit operation */
intel_pipe_update_start(new_crtc_state);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..bbdeb3be64e6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
++

Re: [PATCH] drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1

2019-10-11 Thread Hans de Goede

Hi,

On 10-10-2019 18:59, Daniel Vetter wrote:

On Thu, Oct 10, 2019 at 6:28 PM Hans de Goede  wrote:


Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being a userspace bug, not sending unnecessary
udev events is a good idea in general.


I think even better would be getting rid of the load/unload callbacks,
this issue here isn't the only problem with them.

Reviewed-by: Daniel Vetter 


Thanks,


I guess also cc: stable material?


Yes.

amdgpu maintainers, can you please add a Cc: stable while merging?
Let me know if you want a new version with this added.

Regards,

Hans




BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 35 -
  2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f8aaf655a9f..2a00a36106b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1048,6 +1048,41 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
 return -ENODEV;
 }

+#ifdef CONFIG_DRM_AMDGPU_SI
+   if (!amdgpu_si_support) {
+   switch (flags & AMD_ASIC_MASK) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   case CHIP_VERDE:
+   case CHIP_OLAND:
+   case CHIP_HAINAN:
+   dev_info(>dev,
+"SI support provided by radeon.\n");
+   dev_info(>dev,
+"Use radeon.si_support=0 amdgpu.si_support=1 to 
override.\n"
+   );
+   return -ENODEV;
+   }
+   }
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+   if (!amdgpu_cik_support) {
+   switch (flags & AMD_ASIC_MASK) {
+   case CHIP_KAVERI:
+   case CHIP_BONAIRE:
+   case CHIP_HAWAII:
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   dev_info(>dev,
+"CIK support provided by radeon.\n");
+   dev_info(>dev,
+"Use radeon.cik_support=0 amdgpu.cik_support=1 to 
override.\n"
+   );
+   return -ENODEV;
+   }
+   }
+#endif
+
 /* Get rid of things like offb */
 ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, 
"amdgpudrmfb");
 if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index f2c097983f48..d55f5baa83d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -144,41 +144,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
 struct amdgpu_device *adev;
 int r, acpi_status;

-#ifdef CONFIG_DRM_AMDGPU_SI
-   if (!amdgpu_si_support) {
-   switch (flags & AMD_ASIC_MASK) {
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   dev_info(dev->dev,
-"SI support provided by radeon.\n");
-   dev_info(dev->dev,
-"Use radeon.si_support=0 amdgpu.si_support=1 to 
override.\n"
-   );
-   return -ENODEV;
-   }
-   }
-#endif
-#ifdef CONFIG_DRM_AMDGPU_CIK
-   if (!amdgpu_cik_support) {
-   switch (flags & AMD_ASIC_MASK) {
-   case CHIP_KAVERI:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   dev_info(dev->dev,
-"CIK support provided by radeon.\n");
-   dev_info(dev->dev,
-"Use radeon.cik_support=0 amdgpu.cik_support=1 to 
override.\n"
-   );
-   return -ENODEV;
-   }
-   }
-#endif
-
 adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
 if (adev == NULL) {
 return -ENOMEM;
--
2.23.0






__

[PATCH] drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1

2019-10-10 Thread Hans de Goede
Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being a userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 35 -
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f8aaf655a9f..2a00a36106b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1048,6 +1048,41 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
 
+#ifdef CONFIG_DRM_AMDGPU_SI
+   if (!amdgpu_si_support) {
+   switch (flags & AMD_ASIC_MASK) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   case CHIP_VERDE:
+   case CHIP_OLAND:
+   case CHIP_HAINAN:
+   dev_info(>dev,
+"SI support provided by radeon.\n");
+   dev_info(>dev,
+"Use radeon.si_support=0 amdgpu.si_support=1 
to override.\n"
+   );
+   return -ENODEV;
+   }
+   }
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+   if (!amdgpu_cik_support) {
+   switch (flags & AMD_ASIC_MASK) {
+   case CHIP_KAVERI:
+   case CHIP_BONAIRE:
+   case CHIP_HAWAII:
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   dev_info(>dev,
+"CIK support provided by radeon.\n");
+   dev_info(>dev,
+"Use radeon.cik_support=0 amdgpu.cik_support=1 
to override.\n"
+   );
+   return -ENODEV;
+   }
+   }
+#endif
+
/* Get rid of things like offb */
ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, 
"amdgpudrmfb");
if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index f2c097983f48..d55f5baa83d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -144,41 +144,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
struct amdgpu_device *adev;
int r, acpi_status;
 
-#ifdef CONFIG_DRM_AMDGPU_SI
-   if (!amdgpu_si_support) {
-   switch (flags & AMD_ASIC_MASK) {
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   dev_info(dev->dev,
-"SI support provided by radeon.\n");
-   dev_info(dev->dev,
-"Use radeon.si_support=0 amdgpu.si_support=1 
to override.\n"
-   );
-   return -ENODEV;
-   }
-   }
-#endif
-#ifdef CONFIG_DRM_AMDGPU_CIK
-   if (!amdgpu_cik_support) {
-   switch (flags & AMD_ASIC_MASK) {
-   case CHIP_KAVERI:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   dev_info(dev->dev,
-"CIK support provided by radeon.\n");
-   dev_info(dev->dev,
-"Use radeon.cik_support=0 amdgpu.cik_support=1 
to override.\n"
-   );
-   return -ENODEV;
-   }
-   }
-#endif
-
adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
if (adev == NULL) {
return -ENOMEM;
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Recent tinydrm -> tiny drm drivers rename causes kernel-doc problems

2019-09-15 Thread Hans de Goede

Hi,

On 15-09-2019 17:00, Noralf Trønnes wrote:

Hi Hans,

Den 15.09.2019 16.32, skrev Hans de Goede:

Hi Noralf,

While doing a "make htmldocs" I just noticed the following errors:

Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/mipi-dbi.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/mipi-dbi.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/mipi-dbi.c

It looks like some of the rst file references to tinydrm related
things need updating.



I don't understand how you get those errors, the final tinydrm doc
reference was removed in commit: drm/tinydrm: Move mipi-dbi

https://cgit.freedesktop.org/drm/drm-misc/commit?id=174102f4de230a1bf85e6ef2f8c83e50b3ba22c9


Ugh, this is my bad, I have cherry-picked part of the series as base
for the gm12u320 cleanup series, but not all of them, sorry for the noise.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Recent tinydrm -> tiny drm drivers rename causes kernel-doc problems

2019-09-15 Thread Hans de Goede

Hi Noralf,

While doing a "make htmldocs" I just noticed the following errors:

Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/mipi-dbi.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/mipi-dbi.c
Error: Cannot open file ./drivers/gpu/drm/tinydrm/mipi-dbi.c

It looks like some of the rst file references to tinydrm related
things need updating.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

2019-09-10 Thread Hans de Goede

Hi,

On 9/10/19 9:50 AM, Michel Dänzer wrote:

On 2019-09-07 10:32 p.m., Hans de Goede wrote:

Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Signed-off-by: Hans de Goede 


Reviewed-by: Michel Dänzer 


Thank you for the review. I've drm push rights, but I guess that radeon/amd
GPU patches are collected by someone @AMD, so I do not need to / should not
push this myself, right?


amdgpu should be changed correspondingly as well.


Good point. I'm currently travelling (@plumbers) I can do this when I'm back 
home,
but feel free to beat me to it (if you do please Cc me to avoid double work).

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

2019-09-07 Thread Hans de Goede
Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 31 +
 drivers/gpu/drm/radeon/radeon_kms.c | 25 ---
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index a6cbe11f79c6..7033f3a38c87 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -325,8 +325,39 @@ bool radeon_device_is_virtual(void);
 static int radeon_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
+   unsigned long flags = 0;
int ret;
 
+   if (!ent)
+   return -ENODEV; /* Avoid NULL-ptr deref in drm_get_pci_dev */
+
+   flags = ent->driver_data;
+
+   if (!radeon_si_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   case CHIP_VERDE:
+   case CHIP_OLAND:
+   case CHIP_HAINAN:
+   dev_info(>dev,
+"SI support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+   if (!radeon_cik_support) {
+   switch (flags & RADEON_FAMILY_MASK) {
+   case CHIP_KAVERI:
+   case CHIP_BONAIRE:
+   case CHIP_HAWAII:
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   dev_info(>dev,
+"CIK support disabled by module param\n");
+   return -ENODEV;
+   }
+   }
+
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 07f7ace42c4b..e85c554eeaa9 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -100,31 +100,6 @@ int radeon_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
struct radeon_device *rdev;
int r, acpi_status;
 
-   if (!radeon_si_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   dev_info(dev->dev,
-"SI support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-   if (!radeon_cik_support) {
-   switch (flags & RADEON_FAMILY_MASK) {
-   case CHIP_KAVERI:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   dev_info(dev->dev,
-"CIK support disabled by module param\n");
-   return -ENODEV;
-   }
-   }
-
rdev = kzalloc(sizeof(struct radeon_device), GFP_KERNEL);
if (rdev == NULL) {
return -ENOMEM;
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] efifb: BGRT: Improve efifb_bgrt_sanity_check

2019-08-19 Thread Hans de Goede

Hi,

On 19-08-19 16:01, Bartlomiej Zolnierkiewicz wrote:


On 8/17/19 10:40 AM, Hans de Goede wrote:

Hi,


Hi Hans,


On 21-07-19 15:19, Hans de Goede wrote:

For various reasons, at least with x86 EFI firmwares, the xoffset and
yoffset in the BGRT info are not always reliable.

Extensive testing has shown that when the info is correct, the
BGRT image is always exactly centered horizontally (the yoffset variable
is more variable and not always predictable).

This commit simplifies / improves the bgrt_sanity_check to simply
check that the BGRT image is exactly centered horizontally and skips
(re)drawing it when it is not.

This fixes the BGRT image sometimes being drawn in the wrong place.

Cc: sta...@vger.kernel.org
Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native 
resolutions")
Signed-off-by: Hans de Goede 


ping? I do not see this one in -next yet, what is the status of this
patch?

Patch queued for v5.4, thanks and sorry for the delay.


No problem, thank you all the maintainer work you do on fbdev.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vboxvideo: Make structure vbox_fb_helper_funcs constant

2019-08-18 Thread Hans de Goede

Hi all,

On 14-08-19 19:36, Hans de Goede wrote:

Hi,

On 14-08-19 19:26, Daniel Vetter wrote:

On Tue, Aug 13, 2019 at 09:57:19AM +0200, Hans de Goede wrote:

Hi,

On 13-08-19 08:25, Nishka Dasgupta wrote:

The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs,
is used only when it is passed as the third argument to
drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it
constant to protect it from unintended modifications.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 


Thank you for the patch, this looks good to me:

Reviewed-by: Hans de Goede 


I'm assuming you'll apply this to drm-misc-next too? Good to state that,
to avoid confusion and coordination issues.


Actually I'm so used to the workflow in other subsystems I was
expecting the subsys maintainer to pick it up. But I know that
is not how it works for the drm subsys and since I'm the vboxvideo
maintainer I guess it makes sense for me to pick this up and push it.

So yes I will pick this up and push it to drm-misc-next, sorry
for the confusion.


I've pushed this to drm-misc-next now.

Regards,

Hans




---
   drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 02537ab9cc08..2b57ea3195f2 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -32,7 +32,7 @@ static const struct pci_device_id pciidlist[] = {
   };
   MODULE_DEVICE_TABLE(pci, pciidlist);
-static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
   .fb_probe = vboxfb_create,
   };




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] efifb: BGRT: Improve efifb_bgrt_sanity_check

2019-08-17 Thread Hans de Goede

Hi,

On 21-07-19 15:19, Hans de Goede wrote:

For various reasons, at least with x86 EFI firmwares, the xoffset and
yoffset in the BGRT info are not always reliable.

Extensive testing has shown that when the info is correct, the
BGRT image is always exactly centered horizontally (the yoffset variable
is more variable and not always predictable).

This commit simplifies / improves the bgrt_sanity_check to simply
check that the BGRT image is exactly centered horizontally and skips
(re)drawing it when it is not.

This fixes the BGRT image sometimes being drawn in the wrong place.

Cc: sta...@vger.kernel.org
Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native 
resolutions")
Signed-off-by: Hans de Goede 


ping? I do not see this one in -next yet, what is the status of this
patch?

Regards,

Hans





---
  drivers/video/fbdev/efifb.c | 27 ++-
  1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index dfa8dd47d19d..5b3cef9bf794 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -122,28 +122,13 @@ static void efifb_copy_bmp(u8 *src, u32 *dst, int width, 
struct screen_info *si)
   */
  static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
  {
-   static const int default_resolutions[][2] = {
-   {  800,  600 },
-   { 1024,  768 },
-   { 1280, 1024 },
-   };
-   u32 i, right_margin;
-
-   for (i = 0; i < ARRAY_SIZE(default_resolutions); i++) {
-   if (default_resolutions[i][0] == si->lfb_width &&
-   default_resolutions[i][1] == si->lfb_height)
-   break;
-   }
-   /* If not a default resolution used for textmode, this should be fine */
-   if (i >= ARRAY_SIZE(default_resolutions))
-   return true;
-
-   /* If the right margin is 5 times smaller then the left one, reject */
-   right_margin = si->lfb_width - (bgrt_tab.image_offset_x + bmp_width);
-   if (right_margin < (bgrt_tab.image_offset_x / 5))
-   return false;
+   /*
+* All x86 firmwares horizontally center the image (the yoffset
+* calculations differ between boards, but xoffset is predictable).
+*/
+   u32 expected_xoffset = (si->lfb_width - bmp_width) / 2;
  
-	return true;

+   return bgrt_tab.image_offset_x == expected_xoffset;
  }
  #else
  static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vboxvideo: Make structure vbox_fb_helper_funcs constant

2019-08-14 Thread Hans de Goede

Hi,

On 14-08-19 19:26, Daniel Vetter wrote:

On Tue, Aug 13, 2019 at 09:57:19AM +0200, Hans de Goede wrote:

Hi,

On 13-08-19 08:25, Nishka Dasgupta wrote:

The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs,
is used only when it is passed as the third argument to
drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it
constant to protect it from unintended modifications.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 


Thank you for the patch, this looks good to me:

Reviewed-by: Hans de Goede 


I'm assuming you'll apply this to drm-misc-next too? Good to state that,
to avoid confusion and coordination issues.


Actually I'm so used to the workflow in other subsystems I was
expecting the subsys maintainer to pick it up. But I know that
is not how it works for the drm subsys and since I'm the vboxvideo
maintainer I guess it makes sense for me to pick this up and push it.

So yes I will pick this up and push it to drm-misc-next, sorry
for the confusion.

Regards,

Hans



---
   drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 02537ab9cc08..2b57ea3195f2 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -32,7 +32,7 @@ static const struct pci_device_id pciidlist[] = {
   };
   MODULE_DEVICE_TABLE(pci, pciidlist);
-static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
.fb_probe = vboxfb_create,
   };




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vboxvideo: Make structure vbox_fb_helper_funcs constant

2019-08-13 Thread Hans de Goede

Hi,

On 13-08-19 08:25, Nishka Dasgupta wrote:

The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs,
is used only when it is passed as the third argument to
drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it
constant to protect it from unintended modifications.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 


Thank you for the patch, this looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 02537ab9cc08..2b57ea3195f2 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -32,7 +32,7 @@ static const struct pci_device_id pciidlist[] = {
  };
  MODULE_DEVICE_TABLE(pci, pciidlist);
  
-static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {

+static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
.fb_probe = vboxfb_create,
  };
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: gm12u320: Some minor cleanups

2019-08-12 Thread Hans de Goede

Hi,

On 01-08-19 16:59, Sam Ravnborg wrote:

Hi Hans.

On Tue, Jul 30, 2019 at 03:38:56PM +0200, Hans de Goede wrote:

3 small cleanups:

1) Drop unused DRIVER_PATCHLEVEL
2) We do not set mode_config.preferred_depth, so instead of passing the
unset mode_config.preferred_depth to drm_fbdev_generic_setup
simply pass 0
3) Use __maybe_unused instead of #ifdef CONFIG_PM around the suspend /
resume functions

Cc: Sam Ravnborg 
Suggested-by: Sam Ravnborg 

If you add:
Suggested-by: Noralf Trønnes 
And adjust to the new location.

Then this is:
Reviewed-by: Sam Ravnborg 


I've just pushed these to drm-misc-next, thank you for your input
and reviews.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: gm12u320: Add -ENODEV to list of errors to ignore

2019-08-11 Thread Hans de Goede
Add -ENODEV to the list of usb-transfer errors which we ignore to
avoid logging Frame update errors when the device gets unplugged.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/tiny/gm12u320.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 4d66765b1125..08a52a67ec9e 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -422,7 +422,7 @@ static void gm12u320_fb_update_work(struct work_struct 
*work)
return;
 err:
/* Do not log errors caused by module unload or device unplug */
-   if (ret != -ECONNRESET && ret != -ESHUTDOWN)
+   if (ret != -ENODEV && ret != -ECONNRESET && ret != -ESHUTDOWN)
GM12U320_ERR("Frame update error: %d\n", ret);
 }
 
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: gm12u320: Do not take a mutex from a wait_event condition

2019-08-11 Thread Hans de Goede
I made the condition of the wait_event_timeout call in
gm12u320_fb_update_work a helper which takes a mutex to make sure
that any writes to fb_update.run or fb_update.fb from other CPU cores
are seen before the check is done.

This is not necessary as the wait_event helpers contain the necessary
barriers for this themselves.

More over it is harmfull since by the time the check is done the task
is no longer in the TASK_RUNNING state and calling mutex_lock while not
in task-running is not allowed, leading to this warning when the kernel
is build with some extra locking checks enabled:

[11947.450011] do not call blocking ops when !TASK_RUNNING; state=2 set at
   [<e4306de6>] prepare_to_wait_event+0x61/0x190

This commit fixes this by dropping the helper and simply directly
checking the condition (without unnecessary locking) in the
wait_event_timeout call.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/tiny/gm12u320.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 4c47aa4de09b..4d66765b1125 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -342,17 +342,6 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
mutex_unlock(>fb_update.lock);
 }
 
-static int gm12u320_fb_update_ready(struct gm12u320_device *gm12u320)
-{
-   int ret;
-
-   mutex_lock(>fb_update.lock);
-   ret = !gm12u320->fb_update.run || gm12u320->fb_update.fb != NULL;
-   mutex_unlock(>fb_update.lock);
-
-   return ret;
-}
-
 static void gm12u320_fb_update_work(struct work_struct *work)
 {
struct gm12u320_device *gm12u320 =
@@ -426,7 +415,8 @@ static void gm12u320_fb_update_work(struct work_struct 
*work)
 * switches back to showing its logo.
 */
wait_event_timeout(gm12u320->fb_update.waitq,
-  gm12u320_fb_update_ready(gm12u320),
+  !gm12u320->fb_update.run ||
+   gm12u320->fb_update.fb != NULL,
   IDLE_TIMEOUT);
}
return;
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: gm12u320: Some minor cleanups

2019-08-11 Thread Hans de Goede

Hi,

On 8/1/19 4:59 PM, Sam Ravnborg wrote:

Hi Hans.

On Tue, Jul 30, 2019 at 03:38:56PM +0200, Hans de Goede wrote:

3 small cleanups:

1) Drop unused DRIVER_PATCHLEVEL
2) We do not set mode_config.preferred_depth, so instead of passing the
unset mode_config.preferred_depth to drm_fbdev_generic_setup
simply pass 0
3) Use __maybe_unused instead of #ifdef CONFIG_PM around the suspend /
resume functions

Cc: Sam Ravnborg 
Suggested-by: Sam Ravnborg 

If you add:
Suggested-by: Noralf Trønnes 
And adjust to the new location.

Then this is:
Reviewed-by: Sam Ravnborg 


Thank you for the review. I will push this to drm-misc-next, with
the suggested changes, tomorrow (when I'm back behind my
workstation which has all the necessary kernel trees).

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: gm12u320: Use DRM_DEV_ERROR everywhere

2019-07-30 Thread Hans de Goede
Previously the driver was using a mix of DRM_ERROR and dev_err, be
consisent and use DRM_DEV_ERROR everywhere instead.

Cc: Sam Ravnborg 
Suggested-by: Sam Ravnborg 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/gm12u320/gm12u320.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/gm12u320/gm12u320.c 
b/drivers/gpu/drm/gm12u320/gm12u320.c
index a60854d7c14c..4c47aa4de09b 100644
--- a/drivers/gpu/drm/gm12u320/gm12u320.c
+++ b/drivers/gpu/drm/gm12u320/gm12u320.c
@@ -44,6 +44,9 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, 
more silent)");
 
 #define GM12U320_BLOCK_COUNT   20
 
+#define GM12U320_ERR(fmt, ...) \
+   DRM_DEV_ERROR(>udev->dev, fmt, ##__VA_ARGS__)
+
 #define MISC_RCV_EPT   1
 #define DATA_RCV_EPT   2
 #define DATA_SND_EPT   3
@@ -219,7 +222,7 @@ static int gm12u320_misc_request(struct gm12u320_device 
*gm12u320,
   usb_sndbulkpipe(gm12u320->udev, MISC_SND_EPT),
   gm12u320->cmd_buf, CMD_SIZE, , CMD_TIMEOUT);
if (ret || len != CMD_SIZE) {
-   dev_err(>udev->dev, "Misc. req. error %d\n", ret);
+   GM12U320_ERR("Misc. req. error %d\n", ret);
return -EIO;
}
 
@@ -229,7 +232,7 @@ static int gm12u320_misc_request(struct gm12u320_device 
*gm12u320,
   gm12u320->cmd_buf, MISC_VALUE_SIZE, ,
   DATA_TIMEOUT);
if (ret || len != MISC_VALUE_SIZE) {
-   dev_err(>udev->dev, "Misc. value error %d\n", ret);
+   GM12U320_ERR("Misc. value error %d\n", ret);
return -EIO;
}
/* cmd_buf[0] now contains the read value, which we don't use */
@@ -240,7 +243,7 @@ static int gm12u320_misc_request(struct gm12u320_device 
*gm12u320,
   gm12u320->cmd_buf, READ_STATUS_SIZE, ,
   CMD_TIMEOUT);
if (ret || len != READ_STATUS_SIZE) {
-   dev_err(>udev->dev, "Misc. status error %d\n", ret);
+   GM12U320_ERR("Misc. status error %d\n", ret);
return -EIO;
}
 
@@ -277,7 +280,7 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
 
vaddr = drm_gem_shmem_vmap(fb->obj[0]);
if (IS_ERR(vaddr)) {
-   DRM_ERROR("failed to vmap fb: %ld\n", PTR_ERR(vaddr));
+   GM12U320_ERR("failed to vmap fb: %ld\n", PTR_ERR(vaddr));
goto put_fb;
}
 
@@ -285,7 +288,7 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
ret = dma_buf_begin_cpu_access(
fb->obj[0]->import_attach->dmabuf, DMA_FROM_DEVICE);
if (ret) {
-   DRM_ERROR("dma_buf_begin_cpu_access err: %d\n", ret);
+   GM12U320_ERR("dma_buf_begin_cpu_access err: %d\n", ret);
goto vunmap;
}
}
@@ -328,7 +331,7 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
ret = dma_buf_end_cpu_access(fb->obj[0]->import_attach->dmabuf,
 DMA_FROM_DEVICE);
if (ret)
-   DRM_ERROR("dma_buf_end_cpu_access err: %d\n", ret);
+   GM12U320_ERR("dma_buf_end_cpu_access err: %d\n", ret);
}
 vunmap:
drm_gem_shmem_vunmap(fb->obj[0], vaddr);
@@ -430,7 +433,7 @@ static void gm12u320_fb_update_work(struct work_struct 
*work)
 err:
/* Do not log errors caused by module unload or device unplug */
if (ret != -ECONNRESET && ret != -ESHUTDOWN)
-   dev_err(>udev->dev, "Frame update error: %d\n", ret);
+   GM12U320_ERR("Frame update error: %d\n", ret);
 }
 
 static void gm12u320_fb_mark_dirty(struct drm_framebuffer *fb,
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: gm12u320: Some minor cleanups

2019-07-30 Thread Hans de Goede
3 small cleanups:

1) Drop unused DRIVER_PATCHLEVEL
2) We do not set mode_config.preferred_depth, so instead of passing the
   unset mode_config.preferred_depth to drm_fbdev_generic_setup
   simply pass 0
3) Use __maybe_unused instead of #ifdef CONFIG_PM around the suspend /
   resume functions

Cc: Sam Ravnborg 
Suggested-by: Sam Ravnborg 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/gm12u320/gm12u320.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/gm12u320/gm12u320.c 
b/drivers/gpu/drm/gm12u320/gm12u320.c
index 3dfe86defefc..a60854d7c14c 100644
--- a/drivers/gpu/drm/gm12u320/gm12u320.c
+++ b/drivers/gpu/drm/gm12u320/gm12u320.c
@@ -33,7 +33,6 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, 
more silent)");
 #define DRIVER_DATE"2019"
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
-#define DRIVER_PATCHLEVEL  1
 
 /*
  * The DLP has an actual width of 854 pixels, but that is not a multiple
@@ -747,7 +746,7 @@ static int gm12u320_usb_probe(struct usb_interface 
*interface,
if (ret)
goto err_put;
 
-   drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
+   drm_fbdev_generic_setup(dev, 0);
 
return 0;
 
@@ -766,9 +765,8 @@ static void gm12u320_usb_disconnect(struct usb_interface 
*interface)
drm_dev_put(dev);
 }
 
-#ifdef CONFIG_PM
-static int gm12u320_suspend(struct usb_interface *interface,
-   pm_message_t message)
+static __maybe_unused int gm12u320_suspend(struct usb_interface *interface,
+  pm_message_t message)
 {
struct drm_device *dev = usb_get_intfdata(interface);
struct gm12u320_device *gm12u320 = dev->dev_private;
@@ -779,7 +777,7 @@ static int gm12u320_suspend(struct usb_interface *interface,
return 0;
 }
 
-static int gm12u320_resume(struct usb_interface *interface)
+static __maybe_unused int gm12u320_resume(struct usb_interface *interface)
 {
struct drm_device *dev = usb_get_intfdata(interface);
struct gm12u320_device *gm12u320 = dev->dev_private;
@@ -790,7 +788,6 @@ static int gm12u320_resume(struct usb_interface *interface)
 
return 0;
 }
-#endif
 
 static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1de1, 0xc102) },
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM

2019-07-30 Thread Hans de Goede

Hi,

On 30-07-19 15:34, Noralf Trønnes wrote:



Den 30.07.2019 15.19, skrev Hans de Goede:

Hi,

On 25-07-19 12:51, Noralf Trønnes wrote:

This makes the tiny drivers visible by default without having to enable a
knob.

Signed-off-by: Noralf Trønnes 
---
   drivers/gpu/drm/Makefile    |  2 +-
   drivers/gpu/drm/tinydrm/Kconfig | 37 +++--
   2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/Kconfig
b/drivers/gpu/drm/tinydrm/Kconfig
index 42b06f4f8989..f8c9a0e71dde 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -1,16 +1,9 @@
   # SPDX-License-Identifier: GPL-2.0-only
-menuconfig DRM_TINYDRM
-    tristate "Support for simple displays"
-    depends on DRM
-    select DRM_KMS_HELPER
-    select DRM_KMS_CMA_HELPER
-    help
-  Choose this option if you have a tinydrm supported display.
-  If M is selected the module will be called tinydrm.
-
   config TINYDRM_HX8357D
   tristate "DRM support for HX8357D display panels"
-    depends on DRM_TINYDRM && SPI
+    depends on DRM && SPI
+    select DRM_KMS_HELPER
+    select DRM_KMS_CMA_HELPER
   select DRM_MIPI_DBI
   select BACKLIGHT_CLASS_DEVICE
   help




drivers/gpu/drm/tinydrm/Makefile has:

obj-$(CONFIG_DRM_TINYDRM)   += core/

And AFAIK at least most of the drivers under drivers/gpu/drm/tinydrm
actually need the tinydrm-core.



This is gone in current drm-misc-next.
It went away with:
drm/tinydrm: Remove tinydrm.ko
https://patchwork.freedesktop.org/series/63811/


Ah I see.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM

2019-07-30 Thread Hans de Goede

Hi,

On 25-07-19 12:51, Noralf Trønnes wrote:

This makes the tiny drivers visible by default without having to enable a
knob.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/Makefile|  2 +-
  drivers/gpu/drm/tinydrm/Kconfig | 37 +++--
  2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 42b06f4f8989..f8c9a0e71dde 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -1,16 +1,9 @@
  # SPDX-License-Identifier: GPL-2.0-only
-menuconfig DRM_TINYDRM
-   tristate "Support for simple displays"
-   depends on DRM
-   select DRM_KMS_HELPER
-   select DRM_KMS_CMA_HELPER
-   help
- Choose this option if you have a tinydrm supported display.
- If M is selected the module will be called tinydrm.
-
  config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
-   depends on DRM_TINYDRM && SPI
+   depends on DRM && SPI
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
select DRM_MIPI_DBI
select BACKLIGHT_CLASS_DEVICE
help




drivers/gpu/drm/tinydrm/Makefile has:

obj-$(CONFIG_DRM_TINYDRM)   += core/

And AFAIK at least most of the drivers under drivers/gpu/drm/tinydrm
actually need the tinydrm-core.

So instead you should make the config option a hidden one
and select it in all the drivers which need it, otherwise
things will no longer work after a clean build AFAICT.

Note that even though the config option now remains, this change:

> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 98c732f925c7..0b30afa7524d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -112,7 +112,7 @@ obj-$(CONFIG_DRM_ARCPGU)+= arc/
>   obj-y+= hisilicon/
>   obj-$(CONFIG_DRM_ZTE)+= zte/
>   obj-$(CONFIG_DRM_MXSFB)  += mxsfb/
> -obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
> +obj-y += tinydrm/
>   obj-$(CONFIG_DRM_PL111) += pl111/
>   obj-$(CONFIG_DRM_TVE200) += tve200/
>   obj-$(CONFIG_DRM_XEN) += xen/

Is still necessary so that when other drivers which do not
depend on the tinydrm core and thus will not do:
select DRM_TINYDRM
will still get build.

Otherwise this series looks good to me and you can add my:

Reviewed-by: Hans de Goede  to it once
this is fixed.

Note that drivers/gpu/drm/cirrus is a single .c file tiny
driver now a days too, so it too could be moved to the new
tiny dir. I was actually planning on doing something similar
to this series once I got one more tiny driver upstream :)

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add Grain Media GM12U320 driver v2

2019-07-30 Thread Hans de Goede

Hi,

On 23-07-19 09:28, Sam Ravnborg wrote:

Hi Hans.

Driver looks good. Nce to see so much functionality in a driver less
than 1000 loc.

Following some bike-shedding only - that should have been sent for v1
already. But I thought better late then never.


Thank you for the feedback I've prepared a small followup cleanup
patch addressing some of your remarks.




+#define DRIVER_NAME"gm12u320"
+#define DRIVER_DESC"Grain Media GM12U320 USB projector display"
+#define DRIVER_DATE"2019"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+#define DRIVER_PATCHLEVEL  1

DRIVER_PATCHLEVEL is not used


Good one, fixed.




+   vaddr = drm_gem_shmem_vmap(fb->obj[0]);
+   if (IS_ERR(vaddr)) {
+   DRM_ERROR("failed to vmap fb: %ld\n", PTR_ERR(vaddr));
+   goto put_fb;
+   }
+
+   if (fb->obj[0]->import_attach) {
+   ret = dma_buf_begin_cpu_access(
+   fb->obj[0]->import_attach->dmabuf, DMA_FROM_DEVICE);
+   if (ret) {
+   DRM_ERROR("dma_buf_begin_cpu_access err: %d\n", ret);
+   goto vunmap;
+   }
+   }

Here the code uses DRM_ERROR("...");



+   /* Do not log errors caused by module unload or device unplug */
+   if (ret != -ECONNRESET && ret != -ESHUTDOWN)
+   dev_err(>udev->dev, "Frame update error: %d\n", ret);
+}

And here dev_err(dev, "...");
It had been more consistent to use DRM_DEV_ERROR(dev, "..."); here.


Good one, I've added a second follow-up patch using DRM_DEV_ERROR
consistently everywhere.


+/* -- */
+/* gm12u320 connector*/
+



+
+#ifdef CONFIG_PM
+static int gm12u320_suspend(struct usb_interface *interface,
+   pm_message_t message)
+{

You can use __maybe_unused to get rid of the #ifdef,


Right, Noralf said that too, but I forgot. I've fixed this in the cleanup
patch.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add Grain Media GM12U320 driver v2

2019-07-21 Thread Hans de Goede

Hi all,

On 21-07-19 15:25, Hans de Goede wrote:

Add a modesetting driver for Grain Media GM12U320 based devices
(primarily Acer C120 projector, but there may be compatible devices).

This is based on the fb driver from Viacheslav Nurmekhamitov:
https://github.com/slavrn/gm12u320

This driver uses drm_simple_display_pipe to deal with all the atomic
stuff, gem_shmem_helper functions for buffer management and
drm_fbdev_generic_setup for fbdev emulation, so that leaves the driver
itself with only the actual code for talking to the gm13u320 chip,
leading to a nice simple and clean driver.

Changes in v2:
-Add drm-misc tree to MAINTAINERS
-Drop mode_config.preferred_depth = 24 / fix fbdev support

Reviewed-by: Noralf Trønnes 
Signed-off-by: Hans de Goede 


I've pushed this to drm-misc-next now, with the DRIVER_PRIME flag
dropped, as that is gone in next.

Regards,

Hans




---
  MAINTAINERS |   6 +
  drivers/gpu/drm/Kconfig |   2 +
  drivers/gpu/drm/Makefile|   1 +
  drivers/gpu/drm/gm12u320/Kconfig|   9 +
  drivers/gpu/drm/gm12u320/Makefile   |   2 +
  drivers/gpu/drm/gm12u320/gm12u320.c | 815 
  6 files changed, 835 insertions(+)
  create mode 100644 drivers/gpu/drm/gm12u320/Kconfig
  create mode 100644 drivers/gpu/drm/gm12u320/Makefile
  create mode 100644 drivers/gpu/drm/gm12u320/gm12u320.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e2db0d467966..3290bcfe67b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5025,6 +5025,12 @@ S:   Maintained
  F:drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
  F:
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
  
+DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS

+M: Hans de Goede 
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/gm12u320/
+
  DRM DRIVER FOR ILITEK ILI9225 PANELS
  M:David Lechner 
  S:Maintained
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 36f900d63979..af82002825ed 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -343,6 +343,8 @@ source "drivers/gpu/drm/panfrost/Kconfig"
  
  source "drivers/gpu/drm/aspeed/Kconfig"
  
+source "drivers/gpu/drm/gm12u320/Kconfig"

+
  # Keep legacy drivers last
  
  menuconfig DRM_LEGACY

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..8a4f851f54a2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
  obj-$(CONFIG_DRM_LIMA)  += lima/
  obj-$(CONFIG_DRM_PANFROST) += panfrost/
  obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
+obj-$(CONFIG_DRM_GM12U320) += gm12u320/
diff --git a/drivers/gpu/drm/gm12u320/Kconfig b/drivers/gpu/drm/gm12u320/Kconfig
new file mode 100644
index ..0882a61c04d5
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0+
+config DRM_GM12U320
+   tristate "GM12U320 driver for USB projectors"
+   depends on DRM && USB
+   select DRM_KMS_HELPER
+   select DRM_GEM_SHMEM_HELPER
+   help
+This is a KMS driver for projectors which use the GM12U320 chipset
+for video transfer over USB2/3, such as the Acer C120 mini projector.
diff --git a/drivers/gpu/drm/gm12u320/Makefile 
b/drivers/gpu/drm/gm12u320/Makefile
new file mode 100644
index ..ea514382f00d
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0+
+obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
diff --git a/drivers/gpu/drm/gm12u320/gm12u320.c 
b/drivers/gpu/drm/gm12u320/gm12u320.c
new file mode 100644
index ..3dfe86defefc
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/gm12u320.c
@@ -0,0 +1,815 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool eco_mode;
+module_param(eco_mode, bool, 0644);
+MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)");
+
+#define DRIVER_NAME"gm12u320"
+#define DRIVER_DESC"Grain Media GM12U320 USB projector display"
+#define DRIVER_DATE"2019"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+#define DRIVER_PATCHLEVEL  1
+
+/*
+ * The DLP has an actual width of 854 pixels, but that is not a multiple
+ * of 8, breaking things left and right, so we export a width of 848.
+ */
+#define GM12U320_USER_WIDTH848
+#define GM12U320_REAL_WIDTH854
+#define GM12U320_HEIGHT480
+
+#define GM12U320_BLOCK_COUNT   20
+
+#define MISC_RCV_EPT   1
+#de

[PATCH] x86/sysfb_efi: Add quirks for some devices with swapped width and height

2019-07-21 Thread Hans de Goede
Some Lenovo 2-in-1s with a detachable keyboard have a portrait screen
but advertise a landscape resolution and pitch, resulting in a messed
up display if we try to show anything on the efifb (because of the wrong
pitch).

This commit fixes this by adding a new DMI match table for devices which
need to have their width and height swapped.

At first I tried to use the existing table for overriding some of the
efifb parameters, but some of the affected devices have variants with
different LCD resolutions which will not work with hardcoded override
values.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1730783
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
 arch/x86/kernel/sysfb_efi.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/x86/kernel/sysfb_efi.c b/arch/x86/kernel/sysfb_efi.c
index 8eb67a670b10..80d5b6720a87 100644
--- a/arch/x86/kernel/sysfb_efi.c
+++ b/arch/x86/kernel/sysfb_efi.c
@@ -230,9 +230,54 @@ static const struct dmi_system_id efifb_dmi_system_table[] 
__initconst = {
{},
 };
 
+/*
+ * Some devices have a portrait LCD but advertise a landscape resolution (and
+ * pitch). We simply swap width and height for these devices so that we can
+ * correctly deal with some of them coming with multiple resolutions.
+ */
+static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = {
+   {
+   /*
+* Lenovo MIIX310-10ICR, only some batches have the troublesome
+* 800x1280 portrait screen. Luckily the portrait version has
+* its own BIOS version, so we match on that.
+*/
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
+   DMI_EXACT_MATCH(DMI_BIOS_VERSION, "1HCN44WW"),
+   },
+   },
+   {
+   /* Lenovo MIIX 320-10ICR with 800x1280 portrait screen */
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION,
+   "Lenovo MIIX 320-10ICR"),
+   },
+   },
+   {
+   /* Lenovo D330 with 800x1280 or 1200x1920 portrait screen */
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION,
+   "Lenovo ideapad D330-10IGM"),
+   },
+   },
+   {},
+};
+
 __init void sysfb_apply_efi_quirks(void)
 {
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI ||
!(screen_info.capabilities & VIDEO_CAPABILITY_SKIP_QUIRKS))
dmi_check_system(efifb_dmi_system_table);
+
+   if (screen_info.orig_video_isVGA == VIDEO_TYPE_EFI &&
+   dmi_check_system(efifb_dmi_swap_width_height)) {
+   u16 temp = screen_info.lfb_width;
+   screen_info.lfb_width = screen_info.lfb_height;
+   screen_info.lfb_height = temp;
+   screen_info.lfb_linelength = 4 * screen_info.lfb_width;
+   }
 }
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Add Grain Media GM12U320 driver v2

2019-07-21 Thread Hans de Goede
Add a modesetting driver for Grain Media GM12U320 based devices
(primarily Acer C120 projector, but there may be compatible devices).

This is based on the fb driver from Viacheslav Nurmekhamitov:
https://github.com/slavrn/gm12u320

This driver uses drm_simple_display_pipe to deal with all the atomic
stuff, gem_shmem_helper functions for buffer management and
drm_fbdev_generic_setup for fbdev emulation, so that leaves the driver
itself with only the actual code for talking to the gm13u320 chip,
leading to a nice simple and clean driver.

Changes in v2:
-Add drm-misc tree to MAINTAINERS
-Drop mode_config.preferred_depth = 24 / fix fbdev support

Reviewed-by: Noralf Trønnes 
Signed-off-by: Hans de Goede 
---
 MAINTAINERS |   6 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/gm12u320/Kconfig|   9 +
 drivers/gpu/drm/gm12u320/Makefile   |   2 +
 drivers/gpu/drm/gm12u320/gm12u320.c | 815 
 6 files changed, 835 insertions(+)
 create mode 100644 drivers/gpu/drm/gm12u320/Kconfig
 create mode 100644 drivers/gpu/drm/gm12u320/Makefile
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e2db0d467966..3290bcfe67b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5025,6 +5025,12 @@ S:   Maintained
 F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
 F: 
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
 
+DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS
+M: Hans de Goede 
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/gm12u320/
+
 DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 36f900d63979..af82002825ed 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -343,6 +343,8 @@ source "drivers/gpu/drm/panfrost/Kconfig"
 
 source "drivers/gpu/drm/aspeed/Kconfig"
 
+source "drivers/gpu/drm/gm12u320/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..8a4f851f54a2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
 obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
+obj-$(CONFIG_DRM_GM12U320) += gm12u320/
diff --git a/drivers/gpu/drm/gm12u320/Kconfig b/drivers/gpu/drm/gm12u320/Kconfig
new file mode 100644
index ..0882a61c04d5
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0+
+config DRM_GM12U320
+   tristate "GM12U320 driver for USB projectors"
+   depends on DRM && USB
+   select DRM_KMS_HELPER
+   select DRM_GEM_SHMEM_HELPER
+   help
+This is a KMS driver for projectors which use the GM12U320 chipset
+for video transfer over USB2/3, such as the Acer C120 mini projector.
diff --git a/drivers/gpu/drm/gm12u320/Makefile 
b/drivers/gpu/drm/gm12u320/Makefile
new file mode 100644
index ..ea514382f00d
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0+
+obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
diff --git a/drivers/gpu/drm/gm12u320/gm12u320.c 
b/drivers/gpu/drm/gm12u320/gm12u320.c
new file mode 100644
index ..3dfe86defefc
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/gm12u320.c
@@ -0,0 +1,815 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool eco_mode;
+module_param(eco_mode, bool, 0644);
+MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)");
+
+#define DRIVER_NAME"gm12u320"
+#define DRIVER_DESC"Grain Media GM12U320 USB projector display"
+#define DRIVER_DATE"2019"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+#define DRIVER_PATCHLEVEL  1
+
+/*
+ * The DLP has an actual width of 854 pixels, but that is not a multiple
+ * of 8, breaking things left and right, so we export a width of 848.
+ */
+#define GM12U320_USER_WIDTH848
+#define GM12U320_REAL_WIDTH854
+#define GM12U320_HEIGHT480
+
+#define GM12U320_BLOCK_COUNT   20
+
+#define MISC_RCV_EPT   1
+#define DATA_RCV_EPT   2
+#define DATA_SND_EPT   3
+#define MISC_SND_EPT   4
+
+#define DATA_BLOCK_HEADER_SIZE 84
+#define DATA_BLOCK_CONTENT_SIZE 

[PATCH] efifb: BGRT: Improve efifb_bgrt_sanity_check

2019-07-21 Thread Hans de Goede
For various reasons, at least with x86 EFI firmwares, the xoffset and
yoffset in the BGRT info are not always reliable.

Extensive testing has shown that when the info is correct, the
BGRT image is always exactly centered horizontally (the yoffset variable
is more variable and not always predictable).

This commit simplifies / improves the bgrt_sanity_check to simply
check that the BGRT image is exactly centered horizontally and skips
(re)drawing it when it is not.

This fixes the BGRT image sometimes being drawn in the wrong place.

Cc: sta...@vger.kernel.org
Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native 
resolutions")
Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/efifb.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index dfa8dd47d19d..5b3cef9bf794 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -122,28 +122,13 @@ static void efifb_copy_bmp(u8 *src, u32 *dst, int width, 
struct screen_info *si)
  */
 static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
 {
-   static const int default_resolutions[][2] = {
-   {  800,  600 },
-   { 1024,  768 },
-   { 1280, 1024 },
-   };
-   u32 i, right_margin;
-
-   for (i = 0; i < ARRAY_SIZE(default_resolutions); i++) {
-   if (default_resolutions[i][0] == si->lfb_width &&
-   default_resolutions[i][1] == si->lfb_height)
-   break;
-   }
-   /* If not a default resolution used for textmode, this should be fine */
-   if (i >= ARRAY_SIZE(default_resolutions))
-   return true;
-
-   /* If the right margin is 5 times smaller then the left one, reject */
-   right_margin = si->lfb_width - (bgrt_tab.image_offset_x + bmp_width);
-   if (right_margin < (bgrt_tab.image_offset_x / 5))
-   return false;
+   /*
+* All x86 firmwares horizontally center the image (the yoffset
+* calculations differ between boards, but xoffset is predictable).
+*/
+   u32 expected_xoffset = (si->lfb_width - bmp_width) / 2;
 
-   return true;
+   return bgrt_tab.image_offset_x == expected_xoffset;
 }
 #else
 static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add Grain Media GM12U320 driver

2019-07-20 Thread Hans de Goede

Hi Noralf,

On 18-07-19 14:07, Noralf Trønnes wrote:



Den 17.07.2019 22.37, skrev Hans de Goede:

Hi Noralf,

Thank you for the review.

On 17-07-19 17:24, Noralf Trønnes wrote:



Den 12.07.2019 20.53, skrev Hans de Goede:

Add a modesetting driver for Grain Media GM12U320 based devices
(primarily Acer C120 projector, but there may be compatible devices).

This is based on the fb driver from Viacheslav Nurmekhamitov:
https://github.com/slavrn/gm12u320

This driver uses drm_simple_display_pipe to deal with all the atomic
stuff, gem_shmem_helper functions for buffer management and
drm_fbdev_generic_setup for fbdev emulation, so that leaves the driver
itself with only the actual code for talking to the gm13u320 chip,
leading to a nice simple and clean driver.


Yeah, it's a lot smaller now than when it was first submitted a couple
of years ago ;-)


Ack, this is much better now.


Signed-off-by: Hans de Goede 
---
   MAINTAINERS |   5 +
   drivers/gpu/drm/Kconfig |   2 +
   drivers/gpu/drm/Makefile    |   1 +
   drivers/gpu/drm/gm12u320/Kconfig    |   9 +
   drivers/gpu/drm/gm12u320/Makefile   |   2 +
   drivers/gpu/drm/gm12u320/gm12u320.c | 817 
   6 files changed, 836 insertions(+)





+static void gm12u320_pipe_update(struct drm_simple_display_pipe *pipe,
+ struct drm_plane_state *old_state)
+{
+    struct drm_plane_state *state = pipe->plane.state;
+    struct drm_crtc *crtc = >crtc;
+    struct drm_rect rect;
+
+    if (drm_atomic_helper_damage_merged(old_state, state, ))
+    gm12u320_fb_mark_dirty(pipe->plane.state->fb, );


I'm about to write a usb display driver myself, so I'm curious about why
you punt off the update to a worker instead of doing the update inline?


There are 2 reasons:

1) Doing the update inline is going to take a while, where as userspace
desktop code expects the flip to be nearly instant, so if we block long
here we are introducing significant latency to various userspace code
paths which is undesirable.

2) The hardware in question falls back to showing a builtin screen
with driver installation instruction if you do not send it a new
frame every 2 seconds. So if a desktop environment is smart (energy
consumption aware) enough to not re-render needlessly and the user
is just sitting there watching at the screen (so the ui is idle),
then without the worker we will get this driver install screen
after 2 seconds instead of the desktop. This is also why the loop
in the worker uses wait_event_timeout() instead of plain wait_event()

Interesting that you are working on an usb display driver, can
you share for which hardware this is?



It's more of a generic usb display solution. This is what I replied to
Sam yesterday when discussing tiny SPI displays:

   When I'm done with the tinydrm cleanup, I'm going to work on an idea I
   have: turn the Raspberry Pi Zero into a $5 USB to
   HDMI/SDTV/DSI/DPI/SPI-display adapter. I'm planning to write a generic
   USB host display driver with a matching Linux OTG device driver.
   I plan to make it easy to do the display OTG side on a microcontroller
   as well. This way it will be possible for manufacturers to do USB
   connected displays of (nearly) all sizes without having to write a
   Linux driver.

I'm going to try and do a generic regmap over USB thing that I can put a
generic usb display on to of. The idea is that this regmap can be used
for generic gpio over usb, adc over usb, etc. I don't know if it will
work out in the end but I'll give it a go.


Interesting, good luck with that.




+
+    if (crtc->state->event) {
+    spin_lock_irq(>dev->event_lock);
+    drm_crtc_send_vblank_event(crtc, crtc->state->event);
+    crtc->state->event = NULL;
+    spin_unlock_irq(>dev->event_lock);
+    }


I'm wondering about this signaling here, you're signaling page flip done
before the display has been updated. Shouldn't you do that in the worker
after the update is sent?


I've considered doing this, but:

When connected over USB2 the maximum speed with which we can send
updates is about 30 frames per second, but this assumes that the
bus idle, if the bus is in use the time per frame will vary wildly,
sending vblank events to userspace with random (bus usage dependent)
intervals is likely to confuse some userspace code, since IIRC at
least some code tries to predict when it needs to start rendering the
next frame to be able to flip to it just before the vblank (the later
the rendering is started the less the latency).

Also I'm afraid that with multiple outputs, some compositors might
limit the framerate to the slowest one.

Another problem is that we do not really know when the flip happens,
looking at the reverse-engineered protocol it seems that the device
has 2 buffers, and we update 1 while the other is being scanned out
and then send a command to flip. The flip will happen after we

Re: [PATCH] drm: Add Grain Media GM12U320 driver

2019-07-17 Thread Hans de Goede

Hi Noralf,

Thank you for the review.

On 17-07-19 17:24, Noralf Trønnes wrote:



Den 12.07.2019 20.53, skrev Hans de Goede:

Add a modesetting driver for Grain Media GM12U320 based devices
(primarily Acer C120 projector, but there may be compatible devices).

This is based on the fb driver from Viacheslav Nurmekhamitov:
https://github.com/slavrn/gm12u320

This driver uses drm_simple_display_pipe to deal with all the atomic
stuff, gem_shmem_helper functions for buffer management and
drm_fbdev_generic_setup for fbdev emulation, so that leaves the driver
itself with only the actual code for talking to the gm13u320 chip,
leading to a nice simple and clean driver.


Yeah, it's a lot smaller now than when it was first submitted a couple
of years ago ;-)


Ack, this is much better now.


Signed-off-by: Hans de Goede 
---
  MAINTAINERS |   5 +
  drivers/gpu/drm/Kconfig |   2 +
  drivers/gpu/drm/Makefile|   1 +
  drivers/gpu/drm/gm12u320/Kconfig|   9 +
  drivers/gpu/drm/gm12u320/Makefile   |   2 +
  drivers/gpu/drm/gm12u320/gm12u320.c | 817 
  6 files changed, 836 insertions(+)
  create mode 100644 drivers/gpu/drm/gm12u320/Kconfig
  create mode 100644 drivers/gpu/drm/gm12u320/Makefile
  create mode 100644 drivers/gpu/drm/gm12u320/gm12u320.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e2db0d467966..754d884eb26b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5025,6 +5025,11 @@ S:   Maintained
  F:drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
  F:
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
  
+DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS

+M: Hans de Goede 


I assume this will be a drm-misc driver:

T:  git git://anongit.freedesktop.org/drm/drm-misc


Ack, will fix for v2.


+S: Maintained
+F: drivers/gpu/drm/gm12u320/
+
  DRM DRIVER FOR ILITEK ILI9225 PANELS
  M:David Lechner 
  S:Maintained





diff --git a/drivers/gpu/drm/gm12u320/gm12u320.c 
b/drivers/gpu/drm/gm12u320/gm12u320.c
new file mode 100644
index ..ccbbd62f444d
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/gm12u320.c





+static void gm12u320_pipe_update(struct drm_simple_display_pipe *pipe,
+struct drm_plane_state *old_state)
+{
+   struct drm_plane_state *state = pipe->plane.state;
+   struct drm_crtc *crtc = >crtc;
+   struct drm_rect rect;
+
+   if (drm_atomic_helper_damage_merged(old_state, state, ))
+   gm12u320_fb_mark_dirty(pipe->plane.state->fb, );


I'm about to write a usb display driver myself, so I'm curious about why
you punt off the update to a worker instead of doing the update inline?


There are 2 reasons:

1) Doing the update inline is going to take a while, where as userspace
desktop code expects the flip to be nearly instant, so if we block long
here we are introducing significant latency to various userspace code
paths which is undesirable.

2) The hardware in question falls back to showing a builtin screen
with driver installation instruction if you do not send it a new
frame every 2 seconds. So if a desktop environment is smart (energy
consumption aware) enough to not re-render needlessly and the user
is just sitting there watching at the screen (so the ui is idle),
then without the worker we will get this driver install screen
after 2 seconds instead of the desktop. This is also why the loop
in the worker uses wait_event_timeout() instead of plain wait_event()

Interesting that you are working on an usb display driver, can
you share for which hardware this is?

A couple of years ago (around the time I posted the first version of
a driver for the gm12u320) I started this side project to add support
for some video over USB devices. I have hardware for; and eventually
hope to add kms support for the following:

 -Fresco Logic FL2000 chip out of tree driver here:
  https://github.com/FrescoLogic/FL2000
  This one is used in manycheap USB3 (A connector) to VGA dongles
 -xf86-video-sisusb supported devices
 -Philips PicoPix PPX2055 libam7xxx / am7xxx based devices:
  https://git.ao2.it/libam7xxx.git/

If you happen to be working on support for one of those, please let
me know so I can avoid doing double work. I hope that now that I've
found some time to properly tackle the gm12u320 case I'll also find
time for some of these other soonish. The simple pipe stuff is really
nice and makes working on this a lot easier, so I'm certainly motivated
to spend some of my spare time on this now :)



+
+   if (crtc->state->event) {
+   spin_lock_irq(>dev->event_lock);
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   spin_unlock_irq(>dev->event_lock);
+   }
+}
+
+static const struct drm_simple_display_pipe_funcs gm12u320_pipe_funcs = {
+   .enable   

[PATCH] drm: Add Grain Media GM12U320 driver

2019-07-12 Thread Hans de Goede
Add a modesetting driver for Grain Media GM12U320 based devices
(primarily Acer C120 projector, but there may be compatible devices).

This is based on the fb driver from Viacheslav Nurmekhamitov:
https://github.com/slavrn/gm12u320

This driver uses drm_simple_display_pipe to deal with all the atomic
stuff, gem_shmem_helper functions for buffer management and
drm_fbdev_generic_setup for fbdev emulation, so that leaves the driver
itself with only the actual code for talking to the gm13u320 chip,
leading to a nice simple and clean driver.

Signed-off-by: Hans de Goede 
---
 MAINTAINERS |   5 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/gm12u320/Kconfig|   9 +
 drivers/gpu/drm/gm12u320/Makefile   |   2 +
 drivers/gpu/drm/gm12u320/gm12u320.c | 817 
 6 files changed, 836 insertions(+)
 create mode 100644 drivers/gpu/drm/gm12u320/Kconfig
 create mode 100644 drivers/gpu/drm/gm12u320/Makefile
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e2db0d467966..754d884eb26b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5025,6 +5025,11 @@ S:   Maintained
 F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
 F: 
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
 
+DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS
+M: Hans de Goede 
+S: Maintained
+F: drivers/gpu/drm/gm12u320/
+
 DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 36f900d63979..af82002825ed 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -343,6 +343,8 @@ source "drivers/gpu/drm/panfrost/Kconfig"
 
 source "drivers/gpu/drm/aspeed/Kconfig"
 
+source "drivers/gpu/drm/gm12u320/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..8a4f851f54a2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
 obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
+obj-$(CONFIG_DRM_GM12U320) += gm12u320/
diff --git a/drivers/gpu/drm/gm12u320/Kconfig b/drivers/gpu/drm/gm12u320/Kconfig
new file mode 100644
index ..0882a61c04d5
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0+
+config DRM_GM12U320
+   tristate "GM12U320 driver for USB projectors"
+   depends on DRM && USB
+   select DRM_KMS_HELPER
+   select DRM_GEM_SHMEM_HELPER
+   help
+This is a KMS driver for projectors which use the GM12U320 chipset
+for video transfer over USB2/3, such as the Acer C120 mini projector.
diff --git a/drivers/gpu/drm/gm12u320/Makefile 
b/drivers/gpu/drm/gm12u320/Makefile
new file mode 100644
index ..ea514382f00d
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0+
+obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
diff --git a/drivers/gpu/drm/gm12u320/gm12u320.c 
b/drivers/gpu/drm/gm12u320/gm12u320.c
new file mode 100644
index ..ccbbd62f444d
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/gm12u320.c
@@ -0,0 +1,817 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool eco_mode;
+module_param(eco_mode, bool, 0644);
+MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)");
+
+#define DRIVER_NAME"gm12u320"
+#define DRIVER_DESC"Grain Media GM12U320 USB projector display"
+#define DRIVER_DATE"2019"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+#define DRIVER_PATCHLEVEL  1
+
+/*
+ * The DLP has an actual width of 854 pixels, but that is not a multiple
+ * of 8, breaking things left and right, so we export a width of 848.
+ */
+#define GM12U320_USER_WIDTH848
+#define GM12U320_REAL_WIDTH854
+#define GM12U320_HEIGHT480
+
+#define GM12U320_BLOCK_COUNT   20
+
+#define MISC_RCV_EPT   1
+#define DATA_RCV_EPT   2
+#define DATA_SND_EPT   3
+#define MISC_SND_EPT   4
+
+#define DATA_BLOCK_HEADER_SIZE 84
+#define DATA_BLOCK_CONTENT_SIZE64512
+#define DATA_BLOCK_FOOTER_SIZE 20
+#define DATA_BLOCK_SIZE(DATA_BLOCK_HEADER_SIZE + \
+DATA_BLOCK_CO

Re: [PATCH 0/1] drm: panel-orientation-quirks: Add extra quirk table entry GPD MicroPC

2019-07-01 Thread Hans de Goede

Hi,

On 28-06-19 13:51, Maxime Ripard wrote:

On Fri, Jun 28, 2019 at 12:04:30PM +0200, Hans de Goede wrote:

Hi all,

On 24-06-19 17:40, Hans de Goede wrote:

Hi All,

Good news I have a contact inside GPD now and from now on their BIOS-es
will have proper sys_vendor and product_name DMI strings. This means that
we no longer need to do BIOS date matches and add a new BIOS date to
drm_panel_orientation_quirks.c for each BIOS update.

The second batch of GPD MicroPC-s being delivered to users already uses
these new strings, this patch adds a quirk for the 90 degree mounted
LCD panel using the new DMI strings.

It would be nice to get this into 5.2, but it is not that urgent, so
I believe that it is best to push this to drm-misc-next-fixes and then
it can get added to 5.2.y once it hits Torvald's tree.

If someone can give this a review (it is a trivial patch really) and
give me an Acked-by then I'll push this to drm-misc-next-fixes.


Maarten, Maxime, ping? Can I get an Acked-by (or Reviewed-by) for this
please so that I can push it to drm-misc-next-fixes ?


Acked-by: Maxime Ripard 


Thanks, pushed to drm-misc-next-fixes.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm: panel-orientation-quirks: Add extra quirk table entry GPD MicroPC

2019-06-28 Thread Hans de Goede

Hi all,

On 24-06-19 17:40, Hans de Goede wrote:

Hi All,

Good news I have a contact inside GPD now and from now on their BIOS-es
will have proper sys_vendor and product_name DMI strings. This means that
we no longer need to do BIOS date matches and add a new BIOS date to
drm_panel_orientation_quirks.c for each BIOS update.

The second batch of GPD MicroPC-s being delivered to users already uses
these new strings, this patch adds a quirk for the 90 degree mounted
LCD panel using the new DMI strings.

It would be nice to get this into 5.2, but it is not that urgent, so
I believe that it is best to push this to drm-misc-next-fixes and then
it can get added to 5.2.y once it hits Torvald's tree.

If someone can give this a review (it is a trivial patch really) and
give me an Acked-by then I'll push this to drm-misc-next-fixes.


Maarten, Maxime, ping? Can I get an Acked-by (or Reviewed-by) for this
please so that I can push it to drm-misc-next-fixes ?

Thanks,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: panel-orientation-quirks: Add extra quirk table entry for GPD MicroPC

2019-06-24 Thread Hans de Goede
Newer GPD MicroPC BIOS versions have proper DMI strings, add an extra quirk
table entry for these new strings. This is good news, as this means that we
no longer have to update the BIOS dates list with every BIOS update.

Fixes: 652b8b086538("drm: panel-orientation-quirks: Add quirk for GPD MicroPC")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index d8a0bcd02f34..ffd95bfeaa94 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -90,6 +90,12 @@ static const struct drm_dmi_panel_orientation_data 
itworks_tw891 = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+static const struct drm_dmi_panel_orientation_data lcd720x1280_rightside_up = {
+   .width = 720,
+   .height = 1280,
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
 static const struct drm_dmi_panel_orientation_data lcd800x1280_rightside_up = {
.width = 800,
.height = 1280,
@@ -123,6 +129,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
},
.driver_data = (void *)_micropc,
+   }, {/* GPD MicroPC (later BIOS versions with proper DMI strings) */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MicroPC"),
+   },
+   .driver_data = (void *)_rightside_up,
}, {/*
 * GPD Pocket, note that the the DMI data is less generic then
 * it seems, devices with a board-vendor of "AMI Corporation"
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/1] drm: panel-orientation-quirks: Add extra quirk table entry GPD MicroPC

2019-06-24 Thread Hans de Goede
Hi All,

Good news I have a contact inside GPD now and from now on their BIOS-es
will have proper sys_vendor and product_name DMI strings. This means that
we no longer need to do BIOS date matches and add a new BIOS date to
drm_panel_orientation_quirks.c for each BIOS update.

The second batch of GPD MicroPC-s being delivered to users already uses
these new strings, this patch adds a quirk for the 90 degree mounted
LCD panel using the new DMI strings.

It would be nice to get this into 5.2, but it is not that urgent, so
I believe that it is best to push this to drm-misc-next-fixes and then
it can get added to 5.2.y once it hits Torvald's tree.

If someone can give this a review (it is a trivial patch really) and
give me an Acked-by then I'll push this to drm-misc-next-fixes.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 3/4] drm/connector: Split out orientation quirk detection

2019-06-23 Thread Hans de Goede
ers/gpu/drm/i915/vlv_dsi.c
@@ -1650,6 +1650,7 @@ static void intel_dsi_add_properties(struct 
intel_connector *connector)
  
  	if (connector->panel.fixed_mode) {

u32 allowed_scalers;
+   int orientation;
  
  		allowed_scalers = BIT(DRM_MODE_SCALE_ASPECT) | BIT(DRM_MODE_SCALE_FULLSCREEN);

if (!HAS_GMCH(dev_priv))


The above chunk seems to be a leftover from the previous version of this series.

Otherwise this patch looks good, with this fixed you can add my:

Reviewed-by: Hans de Goede 

Regards,

Hans




@@ -1660,9 +1661,7 @@ static void intel_dsi_add_properties(struct 
intel_connector *connector)
  
  		connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
  
-		connector->base.display_info.panel_orientation =

-   vlv_dsi_get_panel_orientation(connector);
-   drm_connector_init_panel_orientation_property(
+   drm_connector_init_panel_orientation_property_quirk(
>base,
connector->panel.fixed_mode->hdisplay,
connector->panel.fixed_mode->vdisplay);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 47e749b74e5f..0468fd9a4418 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1370,6 +1370,8 @@ void drm_connector_set_link_status_property(struct 
drm_connector *connector,
  void drm_connector_set_vrr_capable_property(
struct drm_connector *connector, bool capable);
  int drm_connector_init_panel_orientation_property(
+   struct drm_connector *connector);
+int drm_connector_init_panel_orientation_property_quirk(
struct drm_connector *connector, int width, int height);
  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
  int min, int max);



Re: [PATCH 4/5] drm/connector: Split out orientation quirk detection

2019-06-12 Thread Hans de Goede

Hi,

On 12-06-19 02:16, dbasehore . wrote:

On Tue, Jun 11, 2019 at 1:54 AM Hans de Goede  wrote:


Hi,

On 11-06-19 10:08, Jani Nikula wrote:

On Mon, 10 Jun 2019, Derek Basehore  wrote:

This removes the orientation quirk detection from the code to add
an orientation property to a panel. This is used only for legacy x86
systems, yet we'd like to start using this on devicetree systems where
quirk detection like this is not needed.


Not needed, but no harm done either, right?

I guess I'll defer judgement on this to Hans and Ville (Cc'd).


Hmm, I'm not big fan of this change. It adds code duplication and as
other models with the same issue using a different driver or panel-type
show up we will get more code duplication.

Also I'm not convinced that devicetree based platforms will not need
this. The whole devicetree as an ABI thing, which means that all
devicetree bindings need to be set in stone before things are merged
into the mainline, is done solely so that we can get vendors to ship
hardware with the dtb files included in the firmware.


We've posted fixes to the devicetree well after the initial merge into
mainline before, so I don't see what you mean about the bindings being
set in stone.


That was just me repeating the official party line about devicetree.


I also don't really see the point. The devicetree is in
the kernel. If there's some setting in the devicetree that we want to
change, it's effectively the same to make the change in the devicetree
versus some quirk setting. The only difference seems to be that making
the change in the devicetree is cleaner.


I agree with you that devicetree in practice is easy to update after
shipping. But at least whenever I tried to get new bindings reviewed
I was always told that I was not allowed to count on that.


I'm 100% sure that there is e.g. ARM hardware out there which uses
non upright mounted LCD panels (I used to have a few Allwinner
tablets which did this). And given my experience with the quality
of firmware bundled tables like ACPI tables I'm quite sure that
if we ever move to firmware included dtb files that we will need
quirks for those too.


Is there a timeline to start using firmware bundled tables?


Nope, as I said "if we ever move to ...".


Since the
quirk code only uses DMI, it will need to be changed anyways for
firmware bundled devicetree files anyways.

We could consolidate the duplicated code into another function that
calls drm_get_panel_orientation_quirks too. The only reason it's like
it is is because I initially only had the call to
drm_get_panel_orientation_quirk once in the code.


Yes if you can add a new helper for the current callers, then
I'm fine with dropping the quirk handling from
drm_connector_init_panel_orientation_property()

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits

2019-06-11 Thread Hans de Goede

Hi,

On 11-06-19 16:37, Ard Biesheuvel wrote:

On Tue, 11 Jun 2019 at 16:24, Hans de Goede  wrote:


Hi,

On 11-06-19 16:04, Ard Biesheuvel wrote:

On Mon, 10 Jun 2019 at 17:12, Ard Biesheuvel  wrote:


On Wed, 29 May 2019 at 17:46, Hans de Goede  wrote:


Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
reserved. These bits are now used to indicate if the image needs to be
rotated before being displayed.

The efifb code does not support rotating the image before copying it to
the screen.

This commit adds a check for these new bits and if they are set leaves the
fb contents as is instead of trying to use the un-rotated BGRT image.

Signed-off-by: Hans de Goede 


Acked-by: Ard Biesheuvel 



BTW should we make sure that this patch and the efi-bgrt patch get
merged at the same time?


The 2 patches are related but merging them at the same time is not
necessary.


I guess the net result is just that we get
rid of some error in the log, but a rotated BMP will be ignored
otherwise.


Right, worse case (if the bmp fits pre-rotation) it will be displayed
rotated. Note on the one machine I'm aware of which uses these bits
the bmp does not fit pre-rotation, so we end up triggering:

error:
  memunmap(bgrt_image);
  pr_warn("efifb: Ignoring BGRT: unexpected or invalid BMP data\n");
}



Doesn't that mean we may now end up breaking 'quiet', by exchanging a
pr_notice() in the efi-bgrt driver for a pr_warn() in this one?


quiet has only logged pr_err and more severe for as long as I can
remember, so notice / warn does not matter for quiet.

Also for flickerfree boot I've made the quiet cut-off configurable
(CONFIG_CONSOLE_LOGLEVEL_QUIET) and in Fedora at least we set it to only
show messages at KERN_CRIT and more severe levels, since there are
simply too many false-positive pr_err messages in the kernel and
I quickly got tired of the whack-a-mole game.

Regards,

Hans


Re: [PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits

2019-06-11 Thread Hans de Goede

Hi,

On 11-06-19 16:04, Ard Biesheuvel wrote:

On Mon, 10 Jun 2019 at 17:12, Ard Biesheuvel  wrote:


On Wed, 29 May 2019 at 17:46, Hans de Goede  wrote:


Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
reserved. These bits are now used to indicate if the image needs to be
rotated before being displayed.

The efifb code does not support rotating the image before copying it to
the screen.

This commit adds a check for these new bits and if they are set leaves the
fb contents as is instead of trying to use the un-rotated BGRT image.

Signed-off-by: Hans de Goede 


Acked-by: Ard Biesheuvel 



BTW should we make sure that this patch and the efi-bgrt patch get
merged at the same time?


The 2 patches are related but merging them at the same time is not
necessary.


I guess the net result is just that we get
rid of some error in the log, but a rotated BMP will be ignored
otherwise.


Right, worse case (if the bmp fits pre-rotation) it will be displayed
rotated. Note on the one machine I'm aware of which uses these bits
the bmp does not fit pre-rotation, so we end up triggering:

error:
memunmap(bgrt_image);
pr_warn("efifb: Ignoring BGRT: unexpected or invalid BMP data\n");
}

Which this patch replaces with hitting:

if (bgrt_tab.status & 0x06) {
pr_info("efifb: BGRT rotation bits set, not showing boot 
graphics\n");
return;
}

Instead. So at least on the one machine I know of this is 99% cosmetic.


Or is it relevant for userland in some other way?


No.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/connector: Split out orientation quirk detection

2019-06-11 Thread Hans de Goede

Hi,

On 11-06-19 10:08, Jani Nikula wrote:

On Mon, 10 Jun 2019, Derek Basehore  wrote:

This removes the orientation quirk detection from the code to add
an orientation property to a panel. This is used only for legacy x86
systems, yet we'd like to start using this on devicetree systems where
quirk detection like this is not needed.


Not needed, but no harm done either, right?

I guess I'll defer judgement on this to Hans and Ville (Cc'd).


Hmm, I'm not big fan of this change. It adds code duplication and as
other models with the same issue using a different driver or panel-type
show up we will get more code duplication.

Also I'm not convinced that devicetree based platforms will not need
this. The whole devicetree as an ABI thing, which means that all
devicetree bindings need to be set in stone before things are merged
into the mainline, is done solely so that we can get vendors to ship
hardware with the dtb files included in the firmware.

I'm 100% sure that there is e.g. ARM hardware out there which uses
non upright mounted LCD panels (I used to have a few Allwinner
tablets which did this). And given my experience with the quality
of firmware bundled tables like ACPI tables I'm quite sure that
if we ever move to firmware included dtb files that we will need
quirks for those too.

Also calling this "used only for legacy x86 systems" is a bit
unfair IMHO, new UEFI models are still being added to the quirk list
today, for hardware which does not even ship yet. Actually 99%
of the models in the quirk list are UEFI only models, which do
not even support classic PC BIOS booting, so those systems are
anything but legacy.

I believe the only reason we have only had to deal with this on x86
so far is because the OOTB support for most ARM systems is less polished
then that for x86 systems and on ARM systems there are still more
important issues to tackle first.

Regards,

Hans








Side note, I'm about to apply some (minor) conflicting changes in our
-next as soon as I get CI results on it.


BR,
Jani.




Signed-off-by: Derek Basehore 
---
  drivers/gpu/drm/drm_connector.c | 16 
  drivers/gpu/drm/i915/intel_dp.c | 14 +++---
  drivers/gpu/drm/i915/vlv_dsi.c  | 14 ++
  include/drm/drm_connector.h |  2 +-
  4 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e17586aaa80f..58a09b65028b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1894,31 +1894,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
   * drm_connector_init_panel_orientation_property -
   *initialize the connecters panel_orientation property
   * @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
   *
   * This function should only be called for built-in panels, after setting
   * connector->display_info.panel_orientation first (if known).
   *
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * This function will check if the panel_orientation is not
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
+ * orientation" property to the connector.
   *
   * Returns:
   * Zero on success, negative errno on failure.
   */
  int drm_connector_init_panel_orientation_property(
-   struct drm_connector *connector, int width, int height)
+   struct drm_connector *connector)
  {
struct drm_device *dev = connector->dev;
struct drm_display_info *info = >display_info;
struct drm_property *prop;
-   int orientation_quirk;
-
-   orientation_quirk = drm_get_panel_orientation_quirk(width, height);
-   if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
-   info->panel_orientation = orientation_quirk;
  
  	if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)

return 0;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b099a9dc28fd..72ab090ea97a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -40,6 +40,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "i915_debugfs.h"

@@ -7281,9 +7282,16 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
intel_connector->panel.backlight.power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector, pipe);
  
-	if (fixed_mode)

-   drm_connector_init_panel_orientation_property(
-   connector, fixed_mode->hdisplay, fixed_mode->vdisplay);
+   if (fixed_mode) {
+   int 

Re: [PATCH 2/3] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init (v2)

2019-06-08 Thread Hans de Goede

Hi all,

On 05-06-19 20:37, Ville Syrjälä wrote:

On Wed, Jun 05, 2019 at 08:17:34PM +0200, Hans de Goede wrote:

The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.

Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.

Changes in v2:
-Also moves the icl and vlv specific dphy_param_init functions from the
  generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files.

Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved,
otherwise they are completely unchanged.

Signed-off-by: Hans de Goede 


Reviewed-by: Ville Syrjälä 


Thanks, I've just  pushed this series to dinq (now that the CI is done and
happy with it).

Regards,

Hans






---
  drivers/gpu/drm/i915/icl_dsi.c   | 108 ++
  drivers/gpu/drm/i915/intel_dsi.h |   1 +
  drivers/gpu/drm/i915/intel_dsi_vbt.c | 282 +--
  drivers/gpu/drm/i915/vlv_dsi.c   | 170 
  4 files changed, 280 insertions(+), 281 deletions(-)

diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..511c76e788ef 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1363,6 +1363,113 @@ static const struct mipi_dsi_host_ops 
gen11_dsi_host_ops = {
.transfer = gen11_dsi_host_transfer,
  };
  
+#define ICL_PREPARE_CNT_MAX	0x7

+#define ICL_CLK_ZERO_CNT_MAX   0xf
+#define ICL_TRAIL_CNT_MAX  0x7
+#define ICL_TCLK_PRE_CNT_MAX   0x3
+#define ICL_TCLK_POST_CNT_MAX  0x7
+#define ICL_HS_ZERO_CNT_MAX0xf
+#define ICL_EXIT_ZERO_CNT_MAX  0x7
+
+static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
+{
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
+   u32 tlpx_ns;
+   u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
+   u32 ths_prepare_ns, tclk_trail_ns;
+   u32 hs_zero_cnt;
+   u32 tclk_pre_cnt, tclk_post_cnt;
+
+   tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
+
+   tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
+   ths_prepare_ns = max(mipi_config->ths_prepare,
+mipi_config->tclk_prepare);
+
+   /*
+* prepare cnt in escape clocks
+* this field represents a hexadecimal value with a precision
+* of 1.2 – i.e. the most significant bit is the integer
+* and the least significant 2 bits are fraction bits.
+* so, the field can represent a range of 0.25 to 1.75
+*/
+   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
+   if (prepare_cnt > ICL_PREPARE_CNT_MAX) {
+   DRM_DEBUG_KMS("prepare_cnt out of range (%d)\n", prepare_cnt);
+   prepare_cnt = ICL_PREPARE_CNT_MAX;
+   }
+
+   /* clk zero count in escape clocks */
+   clk_zero_cnt = DIV_ROUND_UP(mipi_config->tclk_prepare_clkzero -
+   ths_prepare_ns, tlpx_ns);
+   if (clk_zero_cnt > ICL_CLK_ZERO_CNT_MAX) {
+   DRM_DEBUG_KMS("clk_zero_cnt out of range (%d)\n", clk_zero_cnt);
+   clk_zero_cnt = ICL_CLK_ZERO_CNT_MAX;
+   }
+
+   /* trail cnt in escape clocks*/
+   trail_cnt = DIV_ROUND_UP(tclk_trail_ns, tlpx_ns);
+   if (trail_cnt > ICL_TRAIL_CNT_MAX) {
+   DRM_DEBUG_KMS("trail_cnt out of range (%d)\n", trail_cnt);
+   trail_cnt = ICL_TRAIL_CNT_MAX;
+   }
+
+   /* tclk pre count in escape clocks */
+   tclk_pre_cnt = DIV_ROUND_UP(mipi_config->tclk_pre, tlpx_ns);
+   if (tclk_pre_cnt > ICL_TCLK_PRE_CNT_MAX) {
+   DRM_DEBUG_KMS("tclk_pre_cnt out of range (%d)\n", tclk_pre_cnt);
+   tclk_pre_cnt = ICL_TCLK_PRE_CNT_MAX;
+   }
+
+   /* tclk post count in escape clocks */
+   tclk_post_cnt = DIV_ROUND_UP(mipi_config->tclk_post, tlpx_ns);
+   if (tclk_post_cnt > ICL_TCLK_POST_CNT_MAX) {
+   DRM_DEBUG_KMS("tclk_post_cnt out of range (%d)\n", 
tclk_post_cnt);
+   tclk_post_cnt = ICL_TCLK_POST_CNT_MAX;
+   }
+
+   /* hs zero cnt in escape clocks */
+   hs_zero_cnt = DIV_ROUND_UP(mipi_config->ths_prepare_hszero -
+  ths_prepare_ns, tlpx_ns);
+   if (hs_zero_cnt > ICL_HS_ZERO_CNT_MAX) {
+   DRM_DEBUG_KMS("hs_zero_cnt out of range (%d)\n", hs_zero_cnt);
+   hs_zero_cnt = ICL_HS_ZERO_CNT_MAX;
+   }
+
+   /* hs exit zero cnt in escape clocks */
+   exit_zero_cnt = DIV_ROUND_UP(mipi_config->ths_exit, tlpx_ns);
+   if (exit_zero_cnt > ICL_EXIT_ZERO_CNT_MAX) {
+   DRM_DEBUG_KMS("exit_zero_cnt out of range (%d)\n", 
exit_zero_cnt);
+   

Re: [PATCH v2 2/2] drm: panel-orientation-quirks: Add quirk for GPD MicroPC

2019-06-08 Thread Hans de Goede

Hi,

On 07-06-19 16:54, Maxime Ripard wrote:

On Thu, Jun 06, 2019 at 04:03:57PM +0200, Hans de Goede wrote:

Hi,

On 06-06-19 15:38, Maxime Ripard wrote:

On Thu, Jun 06, 2019 at 01:13:40PM +0200, Hans de Goede wrote:

On 06-06-19 11:14, Maxime Ripard wrote:

On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:

GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).

Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.

Signed-off-by: Hans de Goede 


For both patches,
Acked-by: Maxime Ripard 


Thank you, I've pushed both to drm-misc-next now.

Can you add them to drm-misc-fixes please ?

(AFAIK I'm not supposed to do that myself)


You definitely can :)

Now that it's in next though, it's pretty hard to come back in time. I
guess we could just apply it in fixes and let git figure it out, or
revert the one in next. I'm not sure which one is preferred
though.


I thought that the procedure was to get it in -next and then cherry-pick
into -fixes?


If you feel like something should be in fixes, you can definitely
apply it there only.


Git should sort this out without issues when Linus merges -next; or
when we back-merge Linus' tree.


Yeah, looking at the doc, cherry-picking is the one encouraged, so
feel free to cherry-pick them in drm-misc-fixes.


Ok, cherry-picked and pushed, thanks.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm: panel-orientation-quirks: Add quirk for GPD MicroPC

2019-06-06 Thread Hans de Goede

Hi,

On 06-06-19 15:38, Maxime Ripard wrote:

On Thu, Jun 06, 2019 at 01:13:40PM +0200, Hans de Goede wrote:

On 06-06-19 11:14, Maxime Ripard wrote:

On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:

GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).

Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.

Signed-off-by: Hans de Goede 


For both patches,
Acked-by: Maxime Ripard 


Thank you, I've pushed both to drm-misc-next now.

Can you add them to drm-misc-fixes please ?

(AFAIK I'm not supposed to do that myself)


You definitely can :)

Now that it's in next though, it's pretty hard to come back in time. I
guess we could just apply it in fixes and let git figure it out, or
revert the one in next. I'm not sure which one is preferred
though.


I thought that the procedure was to get it in -next and then cherry-pick
into -fixes? Git should sort this out without issues when Linus merges
-next; or when we back-merge Linus' tree.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm: panel-orientation-quirks: Add quirk for GPD MicroPC

2019-06-06 Thread Hans de Goede

Hi,

On 06-06-19 11:14, Maxime Ripard wrote:

On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:

GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).

Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.

Signed-off-by: Hans de Goede 


For both patches,
Acked-by: Maxime Ripard 


Thank you, I've pushed both to drm-misc-next now.

Can you add them to drm-misc-fixes please ?

(AFAIK I'm not supposed to do that myself)

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init (v2)

2019-06-05 Thread Hans de Goede
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.

Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.

Changes in v2:
-Also moves the icl and vlv specific dphy_param_init functions from the
 generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files.

Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved,
otherwise they are completely unchanged.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/icl_dsi.c   | 108 ++
 drivers/gpu/drm/i915/intel_dsi.h |   1 +
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 282 +--
 drivers/gpu/drm/i915/vlv_dsi.c   | 170 
 4 files changed, 280 insertions(+), 281 deletions(-)

diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..511c76e788ef 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1363,6 +1363,113 @@ static const struct mipi_dsi_host_ops 
gen11_dsi_host_ops = {
.transfer = gen11_dsi_host_transfer,
 };
 
+#define ICL_PREPARE_CNT_MAX0x7
+#define ICL_CLK_ZERO_CNT_MAX   0xf
+#define ICL_TRAIL_CNT_MAX  0x7
+#define ICL_TCLK_PRE_CNT_MAX   0x3
+#define ICL_TCLK_POST_CNT_MAX  0x7
+#define ICL_HS_ZERO_CNT_MAX0xf
+#define ICL_EXIT_ZERO_CNT_MAX  0x7
+
+static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
+{
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
+   u32 tlpx_ns;
+   u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
+   u32 ths_prepare_ns, tclk_trail_ns;
+   u32 hs_zero_cnt;
+   u32 tclk_pre_cnt, tclk_post_cnt;
+
+   tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
+
+   tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
+   ths_prepare_ns = max(mipi_config->ths_prepare,
+mipi_config->tclk_prepare);
+
+   /*
+* prepare cnt in escape clocks
+* this field represents a hexadecimal value with a precision
+* of 1.2 – i.e. the most significant bit is the integer
+* and the least significant 2 bits are fraction bits.
+* so, the field can represent a range of 0.25 to 1.75
+*/
+   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
+   if (prepare_cnt > ICL_PREPARE_CNT_MAX) {
+   DRM_DEBUG_KMS("prepare_cnt out of range (%d)\n", prepare_cnt);
+   prepare_cnt = ICL_PREPARE_CNT_MAX;
+   }
+
+   /* clk zero count in escape clocks */
+   clk_zero_cnt = DIV_ROUND_UP(mipi_config->tclk_prepare_clkzero -
+   ths_prepare_ns, tlpx_ns);
+   if (clk_zero_cnt > ICL_CLK_ZERO_CNT_MAX) {
+   DRM_DEBUG_KMS("clk_zero_cnt out of range (%d)\n", clk_zero_cnt);
+   clk_zero_cnt = ICL_CLK_ZERO_CNT_MAX;
+   }
+
+   /* trail cnt in escape clocks*/
+   trail_cnt = DIV_ROUND_UP(tclk_trail_ns, tlpx_ns);
+   if (trail_cnt > ICL_TRAIL_CNT_MAX) {
+   DRM_DEBUG_KMS("trail_cnt out of range (%d)\n", trail_cnt);
+   trail_cnt = ICL_TRAIL_CNT_MAX;
+   }
+
+   /* tclk pre count in escape clocks */
+   tclk_pre_cnt = DIV_ROUND_UP(mipi_config->tclk_pre, tlpx_ns);
+   if (tclk_pre_cnt > ICL_TCLK_PRE_CNT_MAX) {
+   DRM_DEBUG_KMS("tclk_pre_cnt out of range (%d)\n", tclk_pre_cnt);
+   tclk_pre_cnt = ICL_TCLK_PRE_CNT_MAX;
+   }
+
+   /* tclk post count in escape clocks */
+   tclk_post_cnt = DIV_ROUND_UP(mipi_config->tclk_post, tlpx_ns);
+   if (tclk_post_cnt > ICL_TCLK_POST_CNT_MAX) {
+   DRM_DEBUG_KMS("tclk_post_cnt out of range (%d)\n", 
tclk_post_cnt);
+   tclk_post_cnt = ICL_TCLK_POST_CNT_MAX;
+   }
+
+   /* hs zero cnt in escape clocks */
+   hs_zero_cnt = DIV_ROUND_UP(mipi_config->ths_prepare_hszero -
+  ths_prepare_ns, tlpx_ns);
+   if (hs_zero_cnt > ICL_HS_ZERO_CNT_MAX) {
+   DRM_DEBUG_KMS("hs_zero_cnt out of range (%d)\n", hs_zero_cnt);
+   hs_zero_cnt = ICL_HS_ZERO_CNT_MAX;
+   }
+
+   /* hs exit zero cnt in escape clocks */
+   exit_zero_cnt = DIV_ROUND_UP(mipi_config->ths_exit, tlpx_ns);
+   if (exit_zero_cnt > ICL_EXIT_ZERO_CNT_MAX) {
+   DRM_DEBUG_KMS("exit_zero_cnt out of range (%d)\n", 
exit_zero_cnt);
+   exit_zero_cnt = ICL_EXIT_ZERO_CNT_MAX;
+   }
+
+   /* clock lane dphy timings */
+   intel_dsi->dphy_reg = (CLK_PREPARE_OVERRIDE |
+  CLK_PREPARE(prepare_cnt) |
+  

[PATCH 1/3] drm/i915/dsi: Move logging of DSI VBT parameters to a helper function

2019-06-05 Thread Hans de Goede
This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++-
 1 file changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 4b8e48db1843..3a187ffabfbd 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -532,6 +532,44 @@ void intel_dsi_msleep(struct intel_dsi *intel_dsi, int 
msec)
msleep(msec);
 }
 
+static void intel_dsi_log_params(struct intel_dsi *intel_dsi)
+{
+   DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
+   DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
+   DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
+   DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
+   DRM_DEBUG_KMS("Video mode format %s\n",
+ intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
+ "non-burst with sync pulse" :
+ intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
+ "non-burst with sync events" :
+ intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
+ "burst" : "");
+   DRM_DEBUG_KMS("Burst mode ratio %d\n", intel_dsi->burst_mode_ratio);
+   DRM_DEBUG_KMS("Reset timer %d\n", intel_dsi->rst_timer_val);
+   DRM_DEBUG_KMS("Eot %s\n", enableddisabled(intel_dsi->eotp_pkt));
+   DRM_DEBUG_KMS("Clockstop %s\n", 
enableddisabled(!intel_dsi->clock_stop));
+   DRM_DEBUG_KMS("Mode %s\n", intel_dsi->operation_mode ? "command" : 
"video");
+   if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK)
+   DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_FRONT_BACK\n");
+   else if (intel_dsi->dual_link == DSI_DUAL_LINK_PIXEL_ALT)
+   DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_PIXEL_ALT\n");
+   else
+   DRM_DEBUG_KMS("Dual link: NONE\n");
+   DRM_DEBUG_KMS("Pixel Format %d\n", intel_dsi->pixel_format);
+   DRM_DEBUG_KMS("TLPX %d\n", intel_dsi->escape_clk_div);
+   DRM_DEBUG_KMS("LP RX Timeout 0x%x\n", intel_dsi->lp_rx_timeout);
+   DRM_DEBUG_KMS("Turnaround Timeout 0x%x\n", intel_dsi->turn_arnd_val);
+   DRM_DEBUG_KMS("Init Count 0x%x\n", intel_dsi->init_count);
+   DRM_DEBUG_KMS("HS to LP Count 0x%x\n", intel_dsi->hs_to_lp_count);
+   DRM_DEBUG_KMS("LP Byte Clock %d\n", intel_dsi->lp_byte_clk);
+   DRM_DEBUG_KMS("DBI BW Timer 0x%x\n", intel_dsi->bw_timer);
+   DRM_DEBUG_KMS("LP to HS Clock Count 0x%x\n", 
intel_dsi->clk_lp_to_hs_count);
+   DRM_DEBUG_KMS("HS to LP Clock Count 0x%x\n", 
intel_dsi->clk_hs_to_lp_count);
+   DRM_DEBUG_KMS("BTA %s\n",
+   enableddisabled(!(intel_dsi->video_frmt_cfg_bits & 
DISABLE_VIDEO_BTA)));
+}
+
 #define ICL_PREPARE_CNT_MAX0x7
 #define ICL_CLK_ZERO_CNT_MAX   0xf
 #define ICL_TRAIL_CNT_MAX  0x7
@@ -635,6 +673,8 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
 HS_TRAIL(trail_cnt) |
 HS_EXIT_OVERRIDE |
 HS_EXIT(exit_zero_cnt));
+
+   intel_dsi_log_params(intel_dsi);
 }
 
 static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
@@ -794,6 +834,8 @@ static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
DIV_ROUND_UP(2 * tlpx_ui + trail_cnt * 2 + 8,
8);
intel_dsi->clk_hs_to_lp_count += extra_byte_count;
+
+   intel_dsi_log_params(intel_dsi);
 }
 
 bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
@@ -888,41 +930,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
else
vlv_dphy_param_init(intel_dsi);
 
-   DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
-   DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
-   DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
-   DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
-   DRM_DEBUG_KMS("Video mode format %s\n",
- intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
- "non-burst with sync pulse" :
- intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
-

[PATCH 3/3] drm/i915/dsi: Read back pclk set by GOP and use that as pclk (v3)

2019-06-05 Thread Hans de Goede
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.

This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.

This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.

Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP

Changes in v3:
-Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks
 in intel_pipe_config_compare() when adjust is set leads to:
 [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...)
 [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...)
-Do the readback and pclk overriding from vlv_dsi_init(), rather then from
 intel_dsi_vbt_init() as the vbt code should not be touching the hw

Reviewed-by: Ville Syrjälä 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/vlv_dsi.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 59500c838b9d..6d96891984a5 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1865,7 +1865,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
struct drm_connector *connector;
-   struct drm_display_mode *fixed_mode;
+   struct drm_display_mode *current_mode, *fixed_mode;
enum port port;
 
DRM_DEBUG_KMS("\n");
@@ -1909,6 +1909,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
intel_connector->get_hw_state = intel_connector_get_hw_state;
 
intel_encoder->port = port;
+   intel_encoder->type = INTEL_OUTPUT_DSI;
+   intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
+   intel_encoder->cloneable = 0;
 
/*
 * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
@@ -1946,6 +1949,20 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
 
+   /* Use clock read-back from current hw-state for fastboot */
+   current_mode = intel_encoder_current_mode(intel_encoder);
+   if (current_mode) {
+   DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
+ intel_dsi->pclk, current_mode->clock);
+   if (intel_fuzzy_clock_check(intel_dsi->pclk,
+   current_mode->clock)) {
+   DRM_DEBUG_KMS("Using GOP pclk\n");
+   intel_dsi->pclk = current_mode->clock;
+   }
+
+   kfree(current_mode);
+   }
+
vlv_dphy_param_init(intel_dsi);
 
/*
@@ -1963,9 +1980,6 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
}
}
 
-   intel_encoder->type = INTEL_OUTPUT_DSI;
-   intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
-   intel_encoder->cloneable = 0;
drm_connector_init(dev, connector, _dsi_connector_funcs,
   DRM_MODE_CONNECTOR_DSI);
 
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init

2019-06-05 Thread Hans de Goede

Hi,

On 04-06-19 19:35, Ville Syrjälä wrote:

On Fri, May 24, 2019 at 06:30:19PM +0200, Hans de Goede wrote:

The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.

Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.

This also removes the single "if (IS_ICELAKE(dev_priv))" check from
intel_dsi_vbt_init making it fully platform agnostic.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/icl_dsi.c   | 1 +
  drivers/gpu/drm/i915/intel_dsi.h | 2 ++
  drivers/gpu/drm/i915/intel_dsi_vbt.c | 9 ++---
  drivers/gpu/drm/i915/vlv_dsi.c   | 2 ++
  4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..0f43ef07efec 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1455,6 +1455,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
  
+	icl_dphy_param_init(intel_dsi);


I think we should move the entire function into this file.


I was thinking the same thing when I was writing the patch, but I was
not 100% sure. I'm glad that you think the same, I will post a
new version with this fixed (both of them).

Regards,

Hans






return;
  
  err:

diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 705a609050c0..a58d3d988d9f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -192,5 +192,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id);
  void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
 enum mipi_seq seq_id);
  void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec);
+void icl_dphy_param_init(struct intel_dsi *intel_dsi);
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi);
  
  #endif /* _INTEL_DSI_H */

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3448e8d51057..022bf59418df 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -578,7 +578,7 @@ static void intel_dsi_log_params(struct intel_dsi 
*intel_dsi)
  #define ICL_HS_ZERO_CNT_MAX   0xf
  #define ICL_EXIT_ZERO_CNT_MAX 0x7
  
-static void icl_dphy_param_init(struct intel_dsi *intel_dsi)

+void icl_dphy_param_init(struct intel_dsi *intel_dsi)
  {
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -677,7 +677,7 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
intel_dsi_log_params(intel_dsi);
  }
  
-static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)

+void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
  {
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -914,11 +914,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
  
  	intel_dsi->burst_mode_ratio = burst_mode_ratio;
  
-	if (INTEL_GEN(dev_priv) >= 11)

-   icl_dphy_param_init(intel_dsi);
-   else
-   vlv_dphy_param_init(intel_dsi);
-
/* delays in VBT are in unit of 100us, so need to convert
 * here in ms
 * Delay (100us) * 100 /1000 = Delay / 10 (ms) */
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index fce8b58f7f93..3329ccf3b346 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1782,6 +1782,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
  
+	vlv_dphy_param_init(intel_dsi);


ditto


+
/*
 * In case of BYT with CRC PMIC, we need to use GPIO for
 * Panel control.
--
2.21.0



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/i915/dsi: Use a fuzzy check for burst mode clock check

2019-06-05 Thread Hans de Goede

Hi,

Thank you for the reviews.

On 04-06-19 19:29, Ville Syrjälä wrote:

On Fri, May 24, 2019 at 07:40:28PM +0200, Hans de Goede wrote:

Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/

The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed

The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.

This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.

Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
  
+			/*

+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+   if (mipi_config->target_burst_mode_freq < bitrate &&
+   intel_fuzzy_clock_check(
+   mipi_config->target_burst_mode_freq,
+   bitrate))
+   mipi_config->target_burst_mode_freq = bitrate;


Maybe should squash these patches together to make the stable
backport less painful?


Good idea, done.


Anyways, seems OK to me.
Reviewed-by: Ville Syrjälä 


And pushed with your Reviewed-by.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits

2019-05-29 Thread Hans de Goede
Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
reserved. These bits are now used to indicate if the image needs to be
rotated before being displayed.

The efifb code does not support rotating the image before copying it to
the screen.

This commit adds a check for these new bits and if they are set leaves the
fb contents as is instead of trying to use the un-rotated BGRT image.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/efifb.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 9f39f0c360e0..dfa8dd47d19d 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -169,6 +169,11 @@ static void efifb_show_boot_graphics(struct fb_info *info)
return;
}
 
+   if (bgrt_tab.status & 0x06) {
+   pr_info("efifb: BGRT rotation bits set, not showing boot 
graphics\n");
+   return;
+   }
+
/* Avoid flashing the logo if we're going to print std probe messages */
if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
return;
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c

2019-05-24 Thread Hans de Goede
The next patch in this series uses intel_fuzzy_clock_check from the
vlv_dsi.c code.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_drv.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5098228f1302..ceb78f44f087 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11942,7 +11942,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return 0;
 }
 
-static bool intel_fuzzy_clock_check(int clock1, int clock2)
+bool intel_fuzzy_clock_check(int clock1, int clock2)
 {
int diff;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a38b9cff5cd0..e85cd377a652 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1742,6 +1742,7 @@ int vlv_force_pll_on(struct drm_i915_private *dev_priv, 
enum pipe pipe,
 const struct dpll *dpll);
 void vlv_force_pll_off(struct drm_i915_private *dev_priv, enum pipe pipe);
 int lpt_get_iclkip(struct drm_i915_private *dev_priv);
+bool intel_fuzzy_clock_check(int clock1, int clock2);
 
 /* modesetting asserts */
 void assert_panel_unlocked(struct drm_i915_private *dev_priv,
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/i915/dsi: Use a fuzzy check for burst mode clock check

2019-05-24 Thread Hans de Goede
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/

The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed

The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.

This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.

Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
 
+   /*
+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+   if (mipi_config->target_burst_mode_freq < bitrate &&
+   intel_fuzzy_clock_check(
+   mipi_config->target_burst_mode_freq,
+   bitrate))
+   mipi_config->target_burst_mode_freq = bitrate;
+
if (mipi_config->target_burst_mode_freq < bitrate) {
DRM_ERROR("Burst mode freq is less than 
computed\n");
return false;
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH resend for CI] drm/i915/dsi: Call drm_connector_cleanup on vlv_dsi_init error exit path

2019-05-24 Thread Hans de Goede
If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
we've already called drm_connector_init() and we should call
drm_connector_cleanup() to unregister the connector object.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/vlv_dsi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 7ecffd4b9f6b..fce8b58f7f93 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1817,7 +1817,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
 
if (!fixed_mode) {
DRM_DEBUG_KMS("no fixed mode\n");
-   goto err;
+   goto err_cleanup_connector;
}
 
intel_panel_init(_connector->panel, fixed_mode, NULL);
@@ -1827,6 +1827,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
 
return;
 
+err_cleanup_connector:
+   drm_connector_cleanup(_connector->base);
 err:
drm_encoder_cleanup(_encoder->base);
kfree(intel_dsi);
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init

2019-05-24 Thread Hans de Goede
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.

Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.

This also removes the single "if (IS_ICELAKE(dev_priv))" check from
intel_dsi_vbt_init making it fully platform agnostic.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/icl_dsi.c   | 1 +
 drivers/gpu/drm/i915/intel_dsi.h | 2 ++
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 9 ++---
 drivers/gpu/drm/i915/vlv_dsi.c   | 2 ++
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..0f43ef07efec 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1455,6 +1455,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
 
+   icl_dphy_param_init(intel_dsi);
return;
 
 err:
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 705a609050c0..a58d3d988d9f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -192,5 +192,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id);
 void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
 enum mipi_seq seq_id);
 void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec);
+void icl_dphy_param_init(struct intel_dsi *intel_dsi);
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi);
 
 #endif /* _INTEL_DSI_H */
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3448e8d51057..022bf59418df 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -578,7 +578,7 @@ static void intel_dsi_log_params(struct intel_dsi 
*intel_dsi)
 #define ICL_HS_ZERO_CNT_MAX0xf
 #define ICL_EXIT_ZERO_CNT_MAX  0x7
 
-static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
+void icl_dphy_param_init(struct intel_dsi *intel_dsi)
 {
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -677,7 +677,7 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
intel_dsi_log_params(intel_dsi);
 }
 
-static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
 {
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -914,11 +914,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
 
intel_dsi->burst_mode_ratio = burst_mode_ratio;
 
-   if (INTEL_GEN(dev_priv) >= 11)
-   icl_dphy_param_init(intel_dsi);
-   else
-   vlv_dphy_param_init(intel_dsi);
-
/* delays in VBT are in unit of 100us, so need to convert
 * here in ms
 * Delay (100us) * 100 /1000 = Delay / 10 (ms) */
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index fce8b58f7f93..3329ccf3b346 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1782,6 +1782,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
 
+   vlv_dphy_param_init(intel_dsi);
+
/*
 * In case of BYT with CRC PMIC, we need to use GPIO for
 * Panel control.
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm/i915/dsi: Move logging of DSI VBT parameters to a helper function

2019-05-24 Thread Hans de Goede
This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++-
 1 file changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3074448446bc..3448e8d51057 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -532,6 +532,44 @@ void intel_dsi_msleep(struct intel_dsi *intel_dsi, int 
msec)
msleep(msec);
 }
 
+static void intel_dsi_log_params(struct intel_dsi *intel_dsi)
+{
+   DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
+   DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
+   DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
+   DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
+   DRM_DEBUG_KMS("Video mode format %s\n",
+ intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
+ "non-burst with sync pulse" :
+ intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
+ "non-burst with sync events" :
+ intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
+ "burst" : "");
+   DRM_DEBUG_KMS("Burst mode ratio %d\n", intel_dsi->burst_mode_ratio);
+   DRM_DEBUG_KMS("Reset timer %d\n", intel_dsi->rst_timer_val);
+   DRM_DEBUG_KMS("Eot %s\n", enableddisabled(intel_dsi->eotp_pkt));
+   DRM_DEBUG_KMS("Clockstop %s\n", 
enableddisabled(!intel_dsi->clock_stop));
+   DRM_DEBUG_KMS("Mode %s\n", intel_dsi->operation_mode ? "command" : 
"video");
+   if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK)
+   DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_FRONT_BACK\n");
+   else if (intel_dsi->dual_link == DSI_DUAL_LINK_PIXEL_ALT)
+   DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_PIXEL_ALT\n");
+   else
+   DRM_DEBUG_KMS("Dual link: NONE\n");
+   DRM_DEBUG_KMS("Pixel Format %d\n", intel_dsi->pixel_format);
+   DRM_DEBUG_KMS("TLPX %d\n", intel_dsi->escape_clk_div);
+   DRM_DEBUG_KMS("LP RX Timeout 0x%x\n", intel_dsi->lp_rx_timeout);
+   DRM_DEBUG_KMS("Turnaround Timeout 0x%x\n", intel_dsi->turn_arnd_val);
+   DRM_DEBUG_KMS("Init Count 0x%x\n", intel_dsi->init_count);
+   DRM_DEBUG_KMS("HS to LP Count 0x%x\n", intel_dsi->hs_to_lp_count);
+   DRM_DEBUG_KMS("LP Byte Clock %d\n", intel_dsi->lp_byte_clk);
+   DRM_DEBUG_KMS("DBI BW Timer 0x%x\n", intel_dsi->bw_timer);
+   DRM_DEBUG_KMS("LP to HS Clock Count 0x%x\n", 
intel_dsi->clk_lp_to_hs_count);
+   DRM_DEBUG_KMS("HS to LP Clock Count 0x%x\n", 
intel_dsi->clk_hs_to_lp_count);
+   DRM_DEBUG_KMS("BTA %s\n",
+   enableddisabled(!(intel_dsi->video_frmt_cfg_bits & 
DISABLE_VIDEO_BTA)));
+}
+
 #define ICL_PREPARE_CNT_MAX0x7
 #define ICL_CLK_ZERO_CNT_MAX   0xf
 #define ICL_TRAIL_CNT_MAX  0x7
@@ -635,6 +673,8 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
 HS_TRAIL(trail_cnt) |
 HS_EXIT_OVERRIDE |
 HS_EXIT(exit_zero_cnt));
+
+   intel_dsi_log_params(intel_dsi);
 }
 
 static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
@@ -794,6 +834,8 @@ static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
DIV_ROUND_UP(2 * tlpx_ui + trail_cnt * 2 + 8,
8);
intel_dsi->clk_hs_to_lp_count += extra_byte_count;
+
+   intel_dsi_log_params(intel_dsi);
 }
 
 bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
@@ -877,41 +919,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
else
vlv_dphy_param_init(intel_dsi);
 
-   DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
-   DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
-   DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
-   DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
-   DRM_DEBUG_KMS("Video mode format %s\n",
- intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
- "non-burst with sync pulse" :
- intel_dsi->video_mode_format == 
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
- "non-burst with sync e

[PATCH 1/4] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c

2019-05-24 Thread Hans de Goede
The next patch in this series uses intel_fuzzy_clock_check from the
vlv_dsi.c code.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_drv.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5098228f1302..ceb78f44f087 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11942,7 +11942,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return 0;
 }
 
-static bool intel_fuzzy_clock_check(int clock1, int clock2)
+bool intel_fuzzy_clock_check(int clock1, int clock2)
 {
int diff;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a38b9cff5cd0..e85cd377a652 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1742,6 +1742,7 @@ int vlv_force_pll_on(struct drm_i915_private *dev_priv, 
enum pipe pipe,
 const struct dpll *dpll);
 void vlv_force_pll_off(struct drm_i915_private *dev_priv, enum pipe pipe);
 int lpt_get_iclkip(struct drm_i915_private *dev_priv);
+bool intel_fuzzy_clock_check(int clock1, int clock2);
 
 /* modesetting asserts */
 void assert_panel_unlocked(struct drm_i915_private *dev_priv,
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/i915/dsi: Read back pclk set by GOP and use that as pclk (v3)

2019-05-24 Thread Hans de Goede
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.

This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.

This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.

Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP

Changes in v3:
-Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks
 in intel_pipe_config_compare() when adjust is set leads to:
 [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...)
 [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...)
-Do the readback and pclk overriding from vlv_dsi_init(), rather then from
 intel_dsi_vbt_init() as the vbt code should not be touching the hw

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/vlv_dsi.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 3329ccf3b346..49975dd84ff4 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1701,7 +1701,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
struct drm_connector *connector;
-   struct drm_display_mode *fixed_mode;
+   struct drm_display_mode *current_mode, *fixed_mode;
enum port port;
 
DRM_DEBUG_KMS("\n");
@@ -1745,6 +1745,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
intel_connector->get_hw_state = intel_connector_get_hw_state;
 
intel_encoder->port = port;
+   intel_encoder->type = INTEL_OUTPUT_DSI;
+   intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
+   intel_encoder->cloneable = 0;
 
/*
 * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
@@ -1782,6 +1785,20 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
 
+   /* Use clock read-back from current hw-state for fastboot */
+   current_mode = intel_encoder_current_mode(intel_encoder);
+   if (current_mode) {
+   DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
+ intel_dsi->pclk, current_mode->clock);
+   if (intel_fuzzy_clock_check(intel_dsi->pclk,
+   current_mode->clock)) {
+   DRM_DEBUG_KMS("Using GOP pclk\n");
+   intel_dsi->pclk = current_mode->clock;
+   }
+
+   kfree(current_mode);
+   }
+
vlv_dphy_param_init(intel_dsi);
 
/*
@@ -1799,9 +1816,6 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
}
}
 
-   intel_encoder->type = INTEL_OUTPUT_DSI;
-   intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
-   intel_encoder->cloneable = 0;
drm_connector_init(dev, connector, _dsi_connector_funcs,
   DRM_MODE_CONNECTOR_DSI);
 
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[[PATCH 0/4] drm/i915/dsi: Read back pclk set by GOP and use that as pclk (version 3)

2019-05-24 Thread Hans de Goede
Hi All,

This is a resend of my 3th attempt to fix the pclk we calculate for
DSI panels and the pclk which the GOP has configured, causing fastboot
to not work.

As requested in the review of earlier versions, this version moves the
overriding of the pclk out of intel_dsi_vbt.c and into vlv_dsi.c.

This series was first posted in December 2018, but has gotten 0 comments.

This resend is rebased on top of 4.12-rc1 and applies cleanly to the
current drm-tip.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dsi: Use a fuzzy check for burst mode clock check

2019-05-24 Thread Hans de Goede

Hi,

On 5/24/19 3:06 PM, Hans de Goede wrote:

Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/

The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed

The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.

This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.

Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 


I just realized that this patch depends on a patch from another series of
mine which exports intel_fuzzy_clock_check, I will resend this as a series
with the patch doing the exporting as first patch, so that the CI can test
this.

Regards,

Hans



---
  drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
  
+			/*

+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+   if (mipi_config->target_burst_mode_freq < bitrate &&
+   intel_fuzzy_clock_check(
+   mipi_config->target_burst_mode_freq,
+   bitrate))
+   mipi_config->target_burst_mode_freq = bitrate;
+
if (mipi_config->target_burst_mode_freq < bitrate) {
DRM_ERROR("Burst mode freq is less than 
computed\n");
return false;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/dsi: Use a fuzzy check for burst mode clock check

2019-05-24 Thread Hans de Goede
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/

The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed

The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.

This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.

Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
 
+   /*
+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+   if (mipi_config->target_burst_mode_freq < bitrate &&
+   intel_fuzzy_clock_check(
+   mipi_config->target_burst_mode_freq,
+   bitrate))
+   mipi_config->target_burst_mode_freq = bitrate;
+
if (mipi_config->target_burst_mode_freq < bitrate) {
DRM_ERROR("Burst mode freq is less than 
computed\n");
return false;
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm: panel-orientation-quirks: Add quirk for GPD MicroPC

2019-05-24 Thread Hans de Goede
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).

Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 98679c831f66..d8a0bcd02f34 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -42,6 +42,14 @@ static const struct drm_dmi_panel_orientation_data 
asus_t100ha = {
.orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
 };
 
+static const struct drm_dmi_panel_orientation_data gpd_micropc = {
+   .width = 720,
+   .height = 1280,
+   .bios_dates = (const char * const []){ "04/26/2019",
+   NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
 static const struct drm_dmi_panel_orientation_data gpd_pocket = {
.width = 1200,
.height = 1920,
@@ -107,6 +115,14 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)_t100ha,
+   }, {/* GPD MicroPC (generic strings, also match on bios date) */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+   },
+   .driver_data = (void *)_micropc,
}, {/*
 * GPD Pocket, note that the the DMI data is less generic then
 * it seems, devices with a board-vendor of "AMI Corporation"
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm: panel-orientation-quirks: Add quirk for GPD pocket2

2019-05-24 Thread Hans de Goede
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).

Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with some extra bios-dates in the future.

Changes in v2:
-Add one more known BIOS date to the list of BIOS dates

Cc: Jurgen Kramer 
Reported-by: Jurgen Kramer 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 521aff99b08a..98679c831f66 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -50,6 +50,14 @@ static const struct drm_dmi_panel_orientation_data 
gpd_pocket = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+static const struct drm_dmi_panel_orientation_data gpd_pocket2 = {
+   .width = 1200,
+   .height = 1920,
+   .bios_dates = (const char * const []){ "06/28/2018", "08/28/2018",
+   "12/07/2018", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
 static const struct drm_dmi_panel_orientation_data gpd_win = {
.width = 720,
.height = 1280,
@@ -112,6 +120,14 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
.driver_data = (void *)_pocket,
+   }, {/* GPD Pocket 2 (generic strings, also match on bios date) */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+   },
+   .driver_data = (void *)_pocket2,
}, {/* GPD Win (same note on DMI match as GPD Pocket) */
.matches = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: panel-orientation-quirks: Add quirk for GPD pocket2

2019-05-21 Thread Hans de Goede
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).

Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with some extra bios-dates in the future.

Cc: Jurgen Kramer 
Reported-by: Jurgen Kramer 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 52e445bb1aa5..b8079b995d97 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -50,6 +50,14 @@ static const struct drm_dmi_panel_orientation_data 
gpd_pocket = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+static const struct drm_dmi_panel_orientation_data gpd_pocket2 = {
+   .width = 1200,
+   .height = 1920,
+   .bios_dates = (const char * const []){ "08/28/2018", "12/07/2018",
+   NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
 static const struct drm_dmi_panel_orientation_data gpd_win = {
.width = 720,
.height = 1280,
@@ -106,6 +114,14 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
.driver_data = (void *)_pocket,
+   }, {/* GPD Pocket 2 (generic strings, also match on bios date) */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+   },
+   .driver_data = (void *)_pocket2,
}, {/* GPD Win (same note on DMI match as GPD Pocket) */
.matches = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500/cdv: Check vbt config bits when detecting lvds panels

2019-04-29 Thread Hans de Goede

Hi,

On 22-04-19 19:54, Patrik Jakobsson wrote:

On Sun, Apr 21, 2019 at 8:46 PM Hans de Goede  wrote:


Hi,

On 16-04-19 13:46, Patrik Jakobsson wrote:

Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Patrik Jakobsson 
Cc: Hans de Goede 
Cc: Ville Syrjälä 


The reporter of https://bugzilla.redhat.com/show_bug.cgi?id=1665766
just got back to me and he confirms that this patch fixes the
false-positive LVDS panel detection on his NAS, without needing
a DMI blacklist.

So it looks like this patch indeed is a better fix then my initial
DMI blacklist approach and from my pov this patch is ready to
go upstream.


Thanks Hans, can I add your review tag?


Erm, then I would need to actually review it first ... done:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
   drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
   drivers/gpu/drm/gma500/intel_bios.c | 3 +++
   drivers/gpu/drm/gma500/psb_drv.h| 1 +
   3 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..9c8446184b17 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_device *dev,
   int pipe;
   u8 pin;

+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
   pin = GMBUS_PORT_PANEL;
   if (!lvds_is_present_in_vbt(dev, )) {
   DRM_DEBUG_KMS("LVDS is not present in VBT\n");
diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 63bde4e86c6a..e019ea271ffc 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_private *dev_priv,
   if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
   dev_priv->edp.support = 1;

+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
   /* This bit means to use 96Mhz for DPLL_A or not */
   if (driver->primary_lfp_id)
   dev_priv->dplla_96mhz = true;
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 941b238bdcc9..bc608ddc3bd1 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
   int lvds_ssc_freq;
   bool is_lvds_on;
   bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
   u32 mipi_ctrl_display;

   unsigned int core_freq;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500/cdv: Check vbt config bits when detecting lvds panels

2019-04-21 Thread Hans de Goede

Hi,

On 16-04-19 13:46, Patrik Jakobsson wrote:

Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Patrik Jakobsson 
Cc: Hans de Goede 
Cc: Ville Syrjälä 


The reporter of https://bugzilla.redhat.com/show_bug.cgi?id=1665766
just got back to me and he confirms that this patch fixes the
false-positive LVDS panel detection on his NAS, without needing
a DMI blacklist.

So it looks like this patch indeed is a better fix then my initial
DMI blacklist approach and from my pov this patch is ready to
go upstream.

Regards,

Hans



---
  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
  drivers/gpu/drm/gma500/intel_bios.c | 3 +++
  drivers/gpu/drm/gma500/psb_drv.h| 1 +
  3 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..9c8446184b17 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_device *dev,
int pipe;
u8 pin;
  
+	if (!dev_priv->lvds_enabled_in_vbt)

+   return;
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, )) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 63bde4e86c6a..e019ea271ffc 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_private *dev_priv,
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->edp.support = 1;
  
+	dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;

+   DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
/* This bit means to use 96Mhz for DPLL_A or not */
if (driver->primary_lfp_id)
dev_priv->dplla_96mhz = true;
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 941b238bdcc9..bc608ddc3bd1 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
int lvds_ssc_freq;
bool is_lvds_on;
bool is_mipi_on;
+   bool lvds_enabled_in_vbt;
u32 mipi_ctrl_display;
  
  	unsigned int core_freq;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist

2019-04-16 Thread Hans de Goede

Hi,

On 16-04-19 16:32, Patrik Jakobsson wrote:

On Wed, Apr 10, 2019 at 1:51 PM Dominik 'Rathann' Mierzejewski
 wrote:


On Wednesday, 10 April 2019 at 13:33, Patrik Jakobsson wrote:

On Wed, Apr 10, 2019 at 1:18 PM Dominik 'Rathann' Mierzejewski
 wrote:


On Wednesday, 10 April 2019 at 11:08, Hans de Goede wrote:

On 10-04-19 11:00, Patrik Jakobsson wrote:

On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede  wrote:

On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:

On 09-04-19 14:05, Patrik Jakobsson wrote:

[...]

I'm not totally against this but not sure about the consequences. Is
there perhaps a better dmi string to match against?


No there are no better DMI strings to match against I'm afraid.


I did load default settings in BIOS setup and there's no change in
behaviour. LVDS gets detected as connected:
$ cat /sys/class/drm/card0-LVDS-1/status
connected

Only VGA output is physically connected at the moment.


To be clear what Dominik means here is that he has a VGA monitor
connected. There is no LVDS panel in this device at all.


Thanks for testing. I dusted off my DN2800MT and tried turning LVDS
on/off in the BIOS. With LVDS disabled gma500 reports it as connected.
When LVDS is enabled in bios I instead get a connected eDP connector.
I'm starting to think that broken VBT parsing might be the actual
problem.


Maybe, but I assume there are CedarView based laptops with LVDS panels
which works, so I suspect this might be more of a bug in your BIOS.

So what is the next step in debugging this?


To add a small twist, I got an updated BIOS from the vendor to fix
another issue (https://bugzilla.kernel.org/show_bug.cgi?id=199117)
and the DMI string has changed to: "CDV W Series 05", so Hans' patch
no longer matches my machine.


Hi Dominik,

Do you have any option to enable/disable LVDS in your BIOS. The BIOS
default might not be to disable LVDS since they apparently solved the
issue on the command line anyway. If there is an option to turn it off
but you still get the same problem, then it is possible that detection
of "LVDS disabled" in the driver might be bad.


No, there's no option to enable/disable LVDS. The machine is a NAS box
and doesn't have an LVDS physically. You can see the motherboard e.g.
here: https://youtu.be/ZYNQvZNGLsE?t=855 .


I've posted a patch: https://patchwork.freedesktop.org/patch/299821/

Previously we only checked for a child device and ignored the lvds
config bits. Hopefully this fixes your problem.


Dominik,

As also discussed in bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1665766#c23

I've started a Fedora kernel test-build with Patrik's patch added,
please test this:
https://koji.fedoraproject.org/koji/taskinfo?taskID=34215831

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist

2019-04-10 Thread Hans de Goede

Hi,

On 10-04-19 11:00, Patrik Jakobsson wrote:

On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede  wrote:


Hi,

On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:

Hello,

On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:

Hi,

On 09-04-19 14:05, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede  wrote:


Hi,

On 09-04-19 11:47, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede  wrote:


Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.

This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.


Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?


I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.

According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html

The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.


I agree that we should try to fix a broken default but are you sure
this will only affect the n5550? IIUC Milstead / Granite Well is an
Intel product / board name and perhaps some of those use LVDS.


Milstead is the name of Intel's NAS reference design:

https://www.hardwarezone.com.my/tech-news-intel-unveils-milstead-platform-nas-devices

I seriously doubt that any NAS-es have a LVDS (laptop/tablet) LCD panel.


Also, if the pre-installed OS solves this on the cmdline then it's
only a problem if the user is trying to install a custom OS on the
device. I would expect such a user to be able to change bios settings.

I'm not totally against this but not sure about the consequences. Is
there perhaps a better dmi string to match against?


No there are no better DMI strings to match against I'm afraid.


I did load default settings in BIOS setup and there's no change in
behaviour. LVDS gets detected as connected:
$ cat /sys/class/drm/card0-LVDS-1/status
connected

Only VGA output is physically connected at the moment.


To be clear what Dominik means here is that he has a VGA monitor
connected. There is no LVDS panel in this device at all.


Thanks for testing. I dusted off my DN2800MT and tried turning LVDS
on/off in the BIOS. With LVDS disabled gma500 reports it as connected.
When LVDS is enabled in bios I instead get a connected eDP connector.
I'm starting to think that broken VBT parsing might be the actual
problem.


Maybe, but I assume there are CedarView based laptops with LVDS panels
which works, so I suspect this might be more of a bug in your BIOS.

So what is the next step in debugging this?

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist

2019-04-10 Thread Hans de Goede

Hi,

On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:

Hello,

On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:

Hi,

On 09-04-19 14:05, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede  wrote:


Hi,

On 09-04-19 11:47, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede  wrote:


Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.

This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.


Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?


I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.

According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html

The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.


I agree that we should try to fix a broken default but are you sure
this will only affect the n5550? IIUC Milstead / Granite Well is an
Intel product / board name and perhaps some of those use LVDS.


Milstead is the name of Intel's NAS reference design:

https://www.hardwarezone.com.my/tech-news-intel-unveils-milstead-platform-nas-devices

I seriously doubt that any NAS-es have a LVDS (laptop/tablet) LCD panel.


Also, if the pre-installed OS solves this on the cmdline then it's
only a problem if the user is trying to install a custom OS on the
device. I would expect such a user to be able to change bios settings.

I'm not totally against this but not sure about the consequences. Is
there perhaps a better dmi string to match against?


No there are no better DMI strings to match against I'm afraid.


I did load default settings in BIOS setup and there's no change in
behaviour. LVDS gets detected as connected:
$ cat /sys/class/drm/card0-LVDS-1/status
connected

Only VGA output is physically connected at the moment.


To be clear what Dominik means here is that he has a VGA monitor
connected. There is no LVDS panel in this device at all.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist

2019-04-09 Thread Hans de Goede

Hi,

On 09-04-19 14:05, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede  wrote:


Hi,

On 09-04-19 11:47, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede  wrote:


Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.

This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.


Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?


I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.

According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html

The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.


I agree that we should try to fix a broken default but are you sure
this will only affect the n5550? IIUC Milstead / Granite Well is an
Intel product / board name and perhaps some of those use LVDS.


Milstead is the name of Intel's NAS reference design:

https://www.hardwarezone.com.my/tech-news-intel-unveils-milstead-platform-nas-devices

I seriously doubt that any NAS-es have a LVDS (laptop/tablet) LCD panel.


Also, if the pre-installed OS solves this on the cmdline then it's
only a problem if the user is trying to install a custom OS on the
device. I would expect such a user to be able to change bios settings.

I'm not totally against this but not sure about the consequences. Is
there perhaps a better dmi string to match against?


No there are no better DMI strings to match against I'm afraid.

Regards,

Hans




BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Hans de Goede 
---
   drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
   1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..268643af114c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
  return false;
   }

+static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
+   {
+   /* Thecus N2800 and N5550 family NAS-es */
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead Platform"),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
+   /* BIOS version is CDV_T X64 */
+   DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
+   },
+   },
+   {}
+};
+
   /**
* cdv_intel_lvds_init - setup LVDS connectors on this device
* @dev: drm device
@@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
  int pipe;
  u8 pin;

+   /*
+* Check blacklist for machines with BIOSes that list an LVDS panel
+* without actually having one.
+*/
+   if (dmi_check_system(cdv_intel_lvds_blacklist)) {
+   dev_info(>pdev->dev, "System is on LVDS blacklist, skipping 
LVDS panel detection\n");
+   return;
+   }
+
  pin = GMBUS_PORT_PANEL;
  if (!lvds_is_present_in_vbt(dev, )) {
  DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--
2.21.0


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist

2019-04-09 Thread Hans de Goede

Hi,

On 09-04-19 11:47, Patrik Jakobsson wrote:

On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede  wrote:


Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.

This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.


Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?


I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.

According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html

The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.

Regards,

Hans




BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..268643af114c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
 return false;
  }

+static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
+   {
+   /* Thecus N2800 and N5550 family NAS-es */
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead Platform"),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
+   /* BIOS version is CDV_T X64 */
+   DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
+   },
+   },
+   {}
+};
+
  /**
   * cdv_intel_lvds_init - setup LVDS connectors on this device
   * @dev: drm device
@@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
 int pipe;
 u8 pin;

+   /*
+* Check blacklist for machines with BIOSes that list an LVDS panel
+* without actually having one.
+*/
+   if (dmi_check_system(cdv_intel_lvds_blacklist)) {
+   dev_info(>pdev->dev, "System is on LVDS blacklist, skipping 
LVDS panel detection\n");
+   return;
+   }
+
 pin = GMBUS_PORT_PANEL;
 if (!lvds_is_present_in_vbt(dev, )) {
 DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--
2.21.0


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/15] drm/vboxvideo: Convert vboxvideo driver to Simple TTM

2019-04-09 Thread Hans de Goede

Hi,

On 08-04-19 11:21, Thomas Zimmermann wrote:

Signed-off-by: Thomas Zimmermann 


Patch looks good to me (although perhaps it needs a commit msg):

Reviewed-by: Hans de Goede 

Regards,

Hans




---
  drivers/gpu/drm/vboxvideo/Kconfig|   1 +
  drivers/gpu/drm/vboxvideo/vbox_drv.h |   6 +-
  drivers/gpu/drm/vboxvideo/vbox_ttm.c | 123 ++-
  3 files changed, 12 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/Kconfig 
b/drivers/gpu/drm/vboxvideo/Kconfig
index c1ca87df81df..e29df360978d 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -4,6 +4,7 @@ config DRM_VBOXVIDEO
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_TTM_HELPER
+   select DRM_SIMPLE_TTM_HELPER
select GENERIC_ALLOCATOR
help
  This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h 
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index 7db4e961805d..d4cfcc6339ef 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -20,6 +20,8 @@
  #include 
  #include 
  
+#include 

+
  #include 
  #include 
  #include 
@@ -78,9 +80,7 @@ struct vbox_private {
  
  	int fb_mtrr;
  
-	struct {

-   struct ttm_bo_device bdev;
-   } ttm;
+   struct drm_simple_ttm ttm;
  
  	struct mutex hw_mutex; /* protects modeset and accel/vbva accesses */

struct work_struct hotplug_work;
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c 
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index a1d64e1ea90c..115ec44636ab 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
@@ -11,128 +11,25 @@
  #include 
  #include "vbox_drv.h"
  
-static inline struct vbox_private *vbox_bdev(struct ttm_bo_device *bd)

-{
-   return container_of(bd, struct vbox_private, ttm.bdev);
-}
-
-static int
-vbox_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
- struct ttm_mem_type_manager *man)
-{
-   switch (type) {
-   case TTM_PL_SYSTEM:
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_MASK_CACHING;
-   man->default_caching = TTM_PL_FLAG_CACHED;
-   break;
-   case TTM_PL_VRAM:
-   man->func = _bo_manager_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
-   man->default_caching = TTM_PL_FLAG_WC;
-   break;
-   default:
-   DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
-static int vbox_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
-  struct ttm_mem_reg *mem)
-{
-   struct ttm_mem_type_manager *man = >man[mem->mem_type];
-   struct vbox_private *vbox = vbox_bdev(bdev);
-
-   mem->bus.addr = NULL;
-   mem->bus.offset = 0;
-   mem->bus.size = mem->num_pages << PAGE_SHIFT;
-   mem->bus.base = 0;
-   mem->bus.is_iomem = false;
-   if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
-   return -EINVAL;
-   switch (mem->mem_type) {
-   case TTM_PL_SYSTEM:
-   /* system memory */
-   return 0;
-   case TTM_PL_VRAM:
-   mem->bus.offset = mem->start << PAGE_SHIFT;
-   mem->bus.base = pci_resource_start(vbox->ddev.pdev, 0);
-   mem->bus.is_iomem = true;
-   break;
-   default:
-   return -EINVAL;
-   }
-   return 0;
-}
-
-static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev,
-struct ttm_mem_reg *mem)
-{
-}
-
-static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
-{
-   ttm_tt_fini(tt);
-   kfree(tt);
-}
-
-static struct ttm_backend_func vbox_tt_backend_func = {
-   .destroy = _ttm_backend_destroy,
-};
-
-static struct ttm_tt *vbox_ttm_tt_create(struct ttm_buffer_object *bo,
-u32 page_flags)
-{
-   struct ttm_tt *tt;
-
-   tt = kzalloc(sizeof(*tt), GFP_KERNEL);
-   if (!tt)
-   return NULL;
-
-   tt->func = _tt_backend_func;
-   if (ttm_tt_init(tt, bo, page_flags)) {
-   kfree(tt);
-   return NULL;
-   }
-
-   return tt;
-}
-
-static struct ttm_bo_driver vbox_bo_driver = {
-   .ttm_tt_create = vbox_ttm_tt_create,
-   .init_mem_type = vbox_bo_init_mem_type,
-   .eviction_valuable = ttm_bo_eviction_valuable,
+static const struct drm_simple_ttm_funcs vbox_simple_ttm_funcs = {
.evict_flags = drm_gem_ttm_bo_driver_evict_flags,
-   .verify_access = drm_gem_ttm_bo_driver_verify_access,
-

  1   2   3   4   5   6   7   8   9   >