From: Hans de Goede <hidden> Date: 2017-11-25 17:33:34
Hi All,
Here is v6 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).
Bartlomiej, can we please have your Acked-by for merging patches 1,
6 and 7 through the drm tree?
New in v6:
-Fix / reference kernel-doc comments
-Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
-Move i915 dsi hardware rotation state read-out to intel_dsi_init()
New in v5:
-Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
-drm_fb_helper: Only use hardware (crtc primary plane) rotation for
180 degrees for now as 9-/270 degrees rotation requires special handling
New in v4:
-Fix drm_fb_helper code setting an invalid rotation value on the primary
plane of disabled/unused crtcs (caught by Fi.CI)
New in v3:
-As requested by Daniel v3 moves the quirks over from the fbdev
subsys to the drm subsys. I've done this by simpy starting with a copy of
the quirk table and eventually removing the fbdev version.
The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
discussed previously the plan is to merge all 7 patches through the
drm tree.
Regards,
Hans
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:35
On some hardware the LCD panel is not mounted upright in the casing,
but upside-down or rotated 90 degrees. In this case we want the console
to automatically be rotated to compensate.
The fbdev-driver may know about the need to rotate. Add a new
fbcon_rotate_hint field to struct fb_info, which gets initialized to -1.
If the fbdev-driver knows that some sort of rotation is necessary then
it can set this field to a FB_ROTATE_* value to tell the fbcon console
driver to rotate the console.
Signed-off-by: Hans de Goede <redacted>
---
drivers/video/fbdev/core/fbcon.c | 18 ++++++++++++------
drivers/video/fbdev/core/fbsysfs.c | 1 +
include/linux/fb.h | 5 +++++
3 files changed, 18 insertions(+), 6 deletions(-)
@@ -465,6 +465,11 @@ struct fb_info {atomic_tcount;intnode;intflags;+/*+*-1bydefault,settoaFB_ROTATE_*valuebythedriver,ifitknows+*alcdisnotmounteduprightandfbconshouldrotatetocompensate.+*/+intfbcon_rotate_hint;structmutexlock;/* Lock for open/release/ioctl funcs */structmutexmm_lock;/* Lock for fb_mmap and smem_* fields */structfb_var_screeninfovar;/* Current var */
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:36
Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.
So at least on x86, we need a quirk table for this. This commit adds a DMI
based quirk table which is initially populated with 5 such devices: Asus
T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.
This quirk table will be used by the drm code to let userspace know that
the display is not mounted upright inside the devices case through a new
panel orientation drm-connector property, as well as to tell fbcon to
rotate the console so that it shows the right way up.
Changes in v5:
-Add a kernel-doc comment documenting drm_get_panel_orientation_quirk()
-Remove board_* matches from the dmi-matches for the VIOS LTH17 laptop,
keeping only the (identical) sys_vendor and product_name matches.
This is necessary because an older version of the bios has
board_vendor set to VOIS instead of VIOS
Changes in v6:
-Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
Reviewed-by: Daniel Vetter <redacted>
Signed-off-by: Hans de Goede <redacted>
---
Documentation/gpu/drm-kms-helpers.rst | 3 +
drivers/gpu/drm/Kconfig | 3 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_panel_orientation_quirks.c | 174 +++++++++++++++++++++++++
include/drm/drm_utils.h | 18 +++
5 files changed, 199 insertions(+)
create mode 100644 drivers/gpu/drm/drm_panel_orientation_quirks.c
create mode 100644 include/drm/drm_utils.h
@@ -0,0 +1,174 @@+/*+*drm_panel_orientation_quirks.c--Quirksfornon-normalpanelorientation+*+*Copyright(C)2017HansdeGoede<hdegoede@redhat.com>+*+*ThisfileissubjecttothetermsandconditionsoftheGNUGeneralPublic+*License.SeethefileCOPYINGinthemaindirectoryofthisarchivefor+*moredetails.+*/++#include<linux/dmi.h>+#include<drm/drm_connector.h>++#ifdef CONFIG_DMI++/*+*Somex86clamshelldesigndevicesuseportraittabletscreensandadisplay+*enginewhichcannotrotateinhardware,soweneedtorotatethefbconto+*compensate.Unfortunatelythese(cheap)devicesalsotypicallyhavequite+*genericDMIdata,sowematchonacombinationofDMIdata,screenresolution+*andalistofknownBIOSdatestoavoidfalsepositives.+*/++structdrm_dmi_panel_orientation_data{+intwidth;+intheight;+constchar*const*bios_dates;+intorientation;+};++staticconststructdrm_dmi_panel_orientation_dataasus_t100ha={+.width=800,+.height=1280,+.orientation=DRM_MODE_PANEL_ORIENTATION_LEFT_UP,+};++staticconststructdrm_dmi_panel_orientation_datagpd_pocket={+.width=1200,+.height=1920,+.bios_dates=(constchar*const[]){"05/26/2017","06/28/2017",+"07/05/2017","08/07/2017",NULL},+.orientation=DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,+};++staticconststructdrm_dmi_panel_orientation_datagpd_win={+.width=720,+.height=1280,+.bios_dates=(constchar*const[]){+"10/25/2016","11/18/2016","12/23/2016","12/26/2016",+"02/21/2017","03/20/2017","05/25/2017",NULL},+.orientation=DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,+};++staticconststructdrm_dmi_panel_orientation_dataitworks_tw891={+.width=800,+.height=1280,+.bios_dates=(constchar*const[]){"10/16/2015",NULL},+.orientation=DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,+};++staticconststructdrm_dmi_panel_orientation_datavios_lth17={+.width=800,+.height=1280,+.orientation=DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,+};++staticconststructdmi_system_idorientation_data[]={+{/* Asus T100HA */+.matches={+DMI_EXACT_MATCH(DMI_SYS_VENDOR,"ASUSTeK COMPUTER INC."),+DMI_EXACT_MATCH(DMI_PRODUCT_NAME,"T100HAN"),+},+.driver_data=(void*)&asus_t100ha,+},{/*+*GPDPocket,notethatthetheDMIdataislessgenericthen+*itseems,deviceswithaboard-vendorof"AMI Corporation"+*arequiterare,asaredeviceswhichhavebothboard-*and*+*product-idsetto"Default String"+*/+.matches={+DMI_EXACT_MATCH(DMI_BOARD_VENDOR,"AMI Corporation"),+DMI_EXACT_MATCH(DMI_BOARD_NAME,"Default string"),+DMI_EXACT_MATCH(DMI_BOARD_SERIAL,"Default string"),+DMI_EXACT_MATCH(DMI_PRODUCT_NAME,"Default string"),+},+.driver_data=(void*)&gpd_pocket,+},{/* GPD Win (same note on DMI match as GPD Pocket) */+.matches={+DMI_EXACT_MATCH(DMI_BOARD_VENDOR,"AMI Corporation"),+DMI_EXACT_MATCH(DMI_BOARD_NAME,"Default string"),+DMI_EXACT_MATCH(DMI_BOARD_SERIAL,"Default string"),+DMI_EXACT_MATCH(DMI_PRODUCT_NAME,"Default string"),+},+.driver_data=(void*)&gpd_win,+},{/* I.T.Works TW891 */+.matches={+DMI_EXACT_MATCH(DMI_SYS_VENDOR,"To be filled by O.E.M."),+DMI_EXACT_MATCH(DMI_PRODUCT_NAME,"TW891"),+DMI_EXACT_MATCH(DMI_BOARD_VENDOR,"To be filled by O.E.M."),+DMI_EXACT_MATCH(DMI_BOARD_NAME,"TW891"),+},+.driver_data=(void*)&itworks_tw891,+},{/* VIOS LTH17 */+.matches={+DMI_EXACT_MATCH(DMI_SYS_VENDOR,"VIOS"),+DMI_EXACT_MATCH(DMI_PRODUCT_NAME,"LTH17"),+},+.driver_data=(void*)&vios_lth17,+},+{}+};++/**+*drm_get_panel_orientation_quirk-Checkforpanelorientationquirks+*@width:widthinpixelsofthepanel+*@height:heightinpixelsofthepanel+*+*Thisfunctionchecksforplatformspecific(e.g.DMIbased)quirks+*providinginfoonpanel_orientationforsystemswherethiscannotbe+*probedfromthehard-/firm-ware.Toavoidfalse-positivethisfunction+*takesthepanelresolutionasargumentandchecksthatagainstthe+*resolutionexpectedbythequirk-tableentry.+*+*Notethisfunctionisalsousedoutsideofthedrm-subsys,byforexample+*theefifbcode.Becauseofthisthisfunctiongetscompiledintoitsown+*kernel-modulewhenbuiltasamodule.+*+*Returns:+*ADRM_MODE_PANEL_ORIENTATION_*valueifthereisaquirkforthissystem,+*orDRM_MODE_PANEL_ORIENTATION_UNKNOWNifthereisnoquirk.+*/+intdrm_get_panel_orientation_quirk(intwidth,intheight)+{+conststructdmi_system_id*match;+conststructdrm_dmi_panel_orientation_data*data;+constchar*bios_date;+inti;++for(match=dmi_first_match(orientation_data);+match;+match=dmi_first_match(match+1)){+data=match->driver_data;++if(data->width!=width||+data->height!=height)+continue;++if(!data->bios_dates)+returndata->orientation;++bios_date=dmi_get_system_info(DMI_BIOS_DATE);+if(!bios_date)+continue;++for(i=0;data->bios_dates[i];i++){+if(!strcmp(data->bios_dates[i],bios_date))+returndata->orientation;+}+}++returnDRM_MODE_PANEL_ORIENTATION_UNKNOWN;+}+EXPORT_SYMBOL(drm_get_panel_orientation_quirk);++#else++/* There are no quirks for non x86 devices yet */+intdrm_get_panel_orientation_quirk(intwidth,intheight)+{+returnDRM_MODE_PANEL_ORIENTATION_UNKNOWN;+}+EXPORT_SYMBOL(drm_get_panel_orientation_quirk);++#endif
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:37
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).
This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.
Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.
Changes in v2:
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
create and attach functions. The caller is expected to set
drm_display_info.panel_orientation before calling this, then this will
check for platform specific quirks overriding the panel_orientation and if
the panel_orientation is set after this then it will attach the property.
Changes in v6:
-Use an enum (with kerneldoc) rather then #defines for
DRM_MODE_PANEL_ORIENTATION_*
Signed-off-by: Hans de Goede <redacted>
Reviewed-by: Daniel Vetter <redacted>
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_connector.c | 73 +++++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 40 ++++++++++++++++++++++
include/drm/drm_mode_config.h | 7 ++++
4 files changed, 121 insertions(+)
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:38
Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.
Changes in v3:
-Use a rotation member in struct drm_fb_helper_crtc and set that from
drm_setup_crtcs instead of looping over all crtc's to find the right one
later
-Since we now no longer look at rotation quirks directly in the fbcon
code, set fb_info.fbcon_rotate_hint when the panel is not mounted upright
and we cannot use hardware rotation
Changes in v4:
-Make drm_fb_helper_init() init drm_fb_helper_crtc.rotation to
DRM_MODE_ROTATE_0 for all crtcs, so that we do not end up setting the
plane_state's rotation to an invalid value for disabled crtcs
(caught by Fi.CI)
Changes in v5:
-Only use hardware (crtc primary plane) rotation for DRM_ROTATE_180,
90 / 270 degree rotation requires special handling which we lack atm
-Add a TODO comment for 90 / 270 degree hardware rotation
-Add some comments to better document the default case when mapping
sw_rotations to fbcon_rotate_hints
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id”894
Reviewed-by: Daniel Vetter <redacted>
Signed-off-by: Hans de Goede <redacted>
---
drivers/gpu/drm/drm_fb_helper.c | 90 ++++++++++++++++++++++++++++++++++++++++-
include/drm/drm_fb_helper.h | 8 ++++
2 files changed, 96 insertions(+), 2 deletions(-)
@@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool activfor(i=0;i<fb_helper->crtc_count;i++){structdrm_mode_set*mode_set=&fb_helper->crtc_info[i].mode_set;+structdrm_plane*primary=mode_set->crtc->primary;++/* Cannot fail as we've already gotten the plane state above */+plane_state=drm_atomic_get_new_plane_state(state,primary);+plane_state->rotation=fb_helper->crtc_info[i].rotation;ret=__drm_atomic_helper_set_config(mode_set,state);if(ret!=0)
@@ -821,6 +826,7 @@ int drm_fb_helper_init(struct drm_device *dev,if(!fb_helper->crtc_info[i].mode_set.connectors)gotoout_free;fb_helper->crtc_info[i].mode_set.num_connectors=0;+fb_helper->crtc_info[i].rotation=DRM_MODE_ROTATE_0;}i=0;
@@ -2338,6 +2344,62 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,returnbest_score;}+/*+*Thisfunctionchecksifrotationisnecessarybecauseofpanelorientation+*andifitis,ifitissupported.+*Ifrotationisnecessaryandsupported,itsgetssetinfb_crtc.rotation.+*Ifrotationisnecessarybutnotsupported,aDRM_MODE_ROTATE_*flaggets+*or-edintofb_helper->sw_rotations.Indrm_setup_crtcs_fb()wecheckifonly+*onebitissetandthenwesetfb_info.fbcon_rotate_hinttomakefbcondo+*theunsupportedrotation.+*/+staticvoiddrm_setup_crtc_rotation(structdrm_fb_helper*fb_helper,+structdrm_fb_helper_crtc*fb_crtc,+structdrm_connector*connector)+{+structdrm_plane*plane=fb_crtc->mode_set.crtc->primary;+uint64_tvalid_mask=0;+inti,rotation;++fb_crtc->rotation=DRM_MODE_ROTATE_0;++switch(connector->display_info.panel_orientation){+caseDRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:+rotation=DRM_MODE_ROTATE_180;+break;+caseDRM_MODE_PANEL_ORIENTATION_LEFT_UP:+rotation=DRM_MODE_ROTATE_90;+break;+caseDRM_MODE_PANEL_ORIENTATION_RIGHT_UP:+rotation=DRM_MODE_ROTATE_270;+break;+default:+rotation=DRM_MODE_ROTATE_0;+}++/*+*TODO:support90/270degreehardwarerotation,+*dependingonthehardwarethismayrequiretheframebuffer+*tobeinaspecifictilingformat.+*/+if(rotation!=DRM_MODE_ROTATE_180||!plane->rotation_property){+fb_helper->sw_rotations|=rotation;+return;+}++for(i=0;i<plane->rotation_property->num_values;i++)+valid_mask|=(1ULL<<plane->rotation_property->values[i]);++if(!(rotation&valid_mask)){+fb_helper->sw_rotations|=rotation;+return;+}++fb_crtc->rotation=rotation;+/* Rotating in hardware, fbcon should not rotate */+fb_helper->sw_rotations|=DRM_MODE_ROTATE_0;+}+staticvoiddrm_setup_crtcs(structdrm_fb_helper*fb_helper,u32width,u32height){
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:39
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.
Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.
So instead we end up reading the rotation from the primary plane.
This commit only implements the panel orientation property for DSI
panels on BYT / CHT hardware, as all known non normal oriented panels
sofar are only found on this hardware.
Changes in v2:
-Read back the rotation applied by the GOP from the primary plane
instead of relying on dev_priv->vbt.dsi.config->rotation, because it
seems that the VBT rotation filed is always 0 even on devices where the
GOP does apply a rotation
Changes in v3:
-Rewrite the code to read back the orientation from the primary
plane to contain all of this in intel_dsi.c instead of poking a bunch
of holes between all the different layers
Changes in v6:
-Move hardware readout to intel_dsi_init()
Signed-off-by: Hans de Goede <redacted>
---
drivers/gpu/drm/i915/intel_dsi.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:40
On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.
The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and set info->fbcon_rotate_hint based on this, so that the fbcon console
on top of efifb gets automatically rotated to compensate for the panel
orientation.
Signed-off-by: Hans de Goede <redacted>
---
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/efifb.c | 21 ++++++++++++++++++++-
2 files changed, 21 insertions(+), 1 deletion(-)
From: Hans de Goede <hidden> Date: 2017-11-25 17:33:41
This is now all handled in the drivers and communicated through
fb_info.fbcon_rotate_hint.
Signed-off-by: Hans de Goede <redacted>
---
drivers/video/fbdev/core/Makefile | 3 -
drivers/video/fbdev/core/fbcon.c | 4 +-
drivers/video/fbdev/core/fbcon.h | 6 --
drivers/video/fbdev/core/fbcon_dmi_quirks.c | 145 ----------------------------
4 files changed, 2 insertions(+), 156 deletions(-)
delete mode 100644 drivers/video/fbdev/core/fbcon_dmi_quirks.c
From: Daniel Vetter <hidden> Date: 2017-11-28 10:25:59
On Sat, Nov 25, 2017 at 06:33:39PM +0100, Hans de Goede wrote:
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.
Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.
So instead we end up reading the rotation from the primary plane.
This commit only implements the panel orientation property for DSI
panels on BYT / CHT hardware, as all known non normal oriented panels
sofar are only found on this hardware.
Changes in v2:
-Read back the rotation applied by the GOP from the primary plane
instead of relying on dev_priv->vbt.dsi.config->rotation, because it
seems that the VBT rotation filed is always 0 even on devices where the
GOP does apply a rotation
Changes in v3:
-Rewrite the code to read back the orientation from the primary
plane to contain all of this in intel_dsi.c instead of poking a bunch
of holes between all the different layers
Changes in v6:
-Move hardware readout to intel_dsi_init()
Yeah, this is what I had in mind. A small hack, but much more well
contained.
Reviewed-by: Daniel Vetter <redacted>
quoted hunk
Signed-off-by: Hans de Goede <redacted>
---
drivers/gpu/drm/i915/intel_dsi.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
From: Daniel Vetter <hidden> Date: 2017-11-28 10:27:58
On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote:
Hi All,
Here is v6 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).
Bartlomiej, can we please have your Acked-by for merging patches 1,
6 and 7 through the drm tree?
New in v6:
-Fix / reference kernel-doc comments
-Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
-Move i915 dsi hardware rotation state read-out to intel_dsi_init()
New in v5:
-Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
-drm_fb_helper: Only use hardware (crtc primary plane) rotation for
180 degrees for now as 9-/270 degrees rotation requires special handling
New in v4:
-Fix drm_fb_helper code setting an invalid rotation value on the primary
plane of disabled/unused crtcs (caught by Fi.CI)
New in v3:
-As requested by Daniel v3 moves the quirks over from the fbdev
subsys to the drm subsys. I've done this by simpy starting with a copy of
the quirk table and eventually removing the fbdev version.
The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
discussed previously the plan is to merge all 7 patches through the
drm tree.
I think from the drm and i915 side of things this all looks ready (well
pls double-check that CI also approves before merging).
Just needs an ack/review from Bart, and then it's probably simplest if you
merge it all through drm-misc - the i915 side is tiny.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Hans de Goede <hidden> Date: 2017-11-28 13:36:09
Hi,
On 28-11-17 11:27, Daniel Vetter wrote:
On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote:
quoted
Hi All,
Here is v6 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).
Bartlomiej, can we please have your Acked-by for merging patches 1,
6 and 7 through the drm tree?
New in v6:
-Fix / reference kernel-doc comments
-Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
-Move i915 dsi hardware rotation state read-out to intel_dsi_init()
New in v5:
-Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
-drm_fb_helper: Only use hardware (crtc primary plane) rotation for
180 degrees for now as 9-/270 degrees rotation requires special handling
New in v4:
-Fix drm_fb_helper code setting an invalid rotation value on the primary
plane of disabled/unused crtcs (caught by Fi.CI)
New in v3:
-As requested by Daniel v3 moves the quirks over from the fbdev
subsys to the drm subsys. I've done this by simpy starting with a copy of
the quirk table and eventually removing the fbdev version.
The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
discussed previously the plan is to merge all 7 patches through the
drm tree.
I think from the drm and i915 side of things this all looks ready (well
pls double-check that CI also approves before merging).
The CI says state is warning, see:
https://patchwork.freedesktop.org/series/32447/
and specifically:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7290/shards.html
Which I find hard to read as I see no tests going to orange, only
3 tests moving to red, which AFAICT is failed. Clicking on the tests
link to get history all 3 tests seem to fail in the same way quite
often (2 out of 3) or somewhat often (the last one). Also the failures
seem unrelated to my changes
So how do I deal with this, resend v7 to get CI to run again and hope
I get a success result for all tests this time ?
Just needs an ack/review from Bart, and then it's probably simplest if you
merge it all through drm-misc - the i915 side is tiny.
Ok, I will wait for an Ack from Bart and then merge this through drm-misc,
thank you for the review.
Regards,
Hans
From: kbuild test robot <hidden> Date: 2017-11-28 15:47:42
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171128-225025
config: i386-randconfig-x003-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/video/fbdev/efifb.c: In function 'efifb_probe':
quoted
drivers/video/fbdev/efifb.c:340:7: error: 'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP' undeclared (first use in this function); did you mean 'DRM_MODE_PRESENT_BOTTOM_FIELD'?
case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DRM_MODE_PRESENT_BOTTOM_FIELD
drivers/video/fbdev/efifb.c:340:7: note: each undeclared identifier is reported only once for each function it appears in
quoted
drivers/video/fbdev/efifb.c:343:7: error: 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP' undeclared (first use in this function); did you mean 'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP'?
case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP
quoted
drivers/video/fbdev/efifb.c:346:7: error: 'DRM_MODE_PANEL_ORIENTATION_RIGHT_UP' undeclared (first use in this function); did you mean 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP'?
case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DRM_MODE_PANEL_ORIENTATION_LEFT_UP
vim +340 drivers/video/fbdev/efifb.c
158
159 static int efifb_probe(struct platform_device *dev)
160 {
161 struct fb_info *info;
162 int err, orientation;
163 unsigned int size_vmode;
164 unsigned int size_remap;
165 unsigned int size_total;
166 char *option = NULL;
167
168 if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
169 return -ENODEV;
170
171 if (fb_get_options("efifb", &option))
172 return -ENODEV;
173 efifb_setup(option);
174
175 /* We don't get linelength from UGA Draw Protocol, only from
176 * EFI Graphics Protocol. So if it's not in DMI, and it's not
177 * passed in from the user, we really can't use the framebuffer.
178 */
179 if (!screen_info.lfb_linelength)
180 return -ENODEV;
181
182 if (!screen_info.lfb_depth)
183 screen_info.lfb_depth = 32;
184 if (!screen_info.pages)
185 screen_info.pages = 1;
186 if (!fb_base_is_valid()) {
187 printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
188 return -ENODEV;
189 }
190 printk(KERN_INFO "efifb: probing for efifb\n");
191
192 /* just assume they're all unset if any are */
193 if (!screen_info.blue_size) {
194 screen_info.blue_size = 8;
195 screen_info.blue_pos = 0;
196 screen_info.green_size = 8;
197 screen_info.green_pos = 8;
198 screen_info.red_size = 8;
199 screen_info.red_pos = 16;
200 screen_info.rsvd_size = 8;
201 screen_info.rsvd_pos = 24;
202 }
203
204 efifb_fix.smem_start = screen_info.lfb_base;
205
206 if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) {
207 u64 ext_lfb_base;
208
209 ext_lfb_base = (u64)(unsigned long)screen_info.ext_lfb_base << 32;
210 efifb_fix.smem_start |= ext_lfb_base;
211 }
212
213 if (bar_resource &&
214 bar_resource->start + bar_offset != efifb_fix.smem_start) {
215 dev_info(&efifb_pci_dev->dev,
216 "BAR has moved, updating efifb address\n");
217 efifb_fix.smem_start = bar_resource->start + bar_offset;
218 }
219
220 efifb_defined.bits_per_pixel = screen_info.lfb_depth;
221 efifb_defined.xres = screen_info.lfb_width;
222 efifb_defined.yres = screen_info.lfb_height;
223 efifb_fix.line_length = screen_info.lfb_linelength;
224
225 /* size_vmode -- that is the amount of memory needed for the
226 * used video mode, i.e. the minimum amount of
227 * memory we need. */
228 size_vmode = efifb_defined.yres * efifb_fix.line_length;
229
230 /* size_total -- all video memory we have. Used for
231 * entries, ressource allocation and bounds
232 * checking. */
233 size_total = screen_info.lfb_size;
234 if (size_total < size_vmode)
235 size_total = size_vmode;
236
237 /* size_remap -- the amount of video memory we are going to
238 * use for efifb. With modern cards it is no
239 * option to simply use size_total as that
240 * wastes plenty of kernel address space. */
241 size_remap = size_vmode * 2;
242 if (size_remap > size_total)
243 size_remap = size_total;
244 if (size_remap % PAGE_SIZE)
245 size_remap += PAGE_SIZE - (size_remap % PAGE_SIZE);
246 efifb_fix.smem_len = size_remap;
247
248 if (request_mem_region(efifb_fix.smem_start, size_remap, "efifb")) {
249 request_mem_succeeded = true;
250 } else {
251 /* We cannot make this fatal. Sometimes this comes from magic
252 spaces our resource handlers simply don't know about */
253 pr_warn("efifb: cannot reserve video memory at 0x%lx\n",
254 efifb_fix.smem_start);
255 }
256
257 info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
258 if (!info) {
259 pr_err("efifb: cannot allocate framebuffer\n");
260 err = -ENOMEM;
261 goto err_release_mem;
262 }
263 platform_set_drvdata(dev, info);
264 info->pseudo_palette = info->par;
265 info->par = NULL;
266
267 info->apertures = alloc_apertures(1);
268 if (!info->apertures) {
269 err = -ENOMEM;
270 goto err_release_fb;
271 }
272 info->apertures->ranges[0].base = efifb_fix.smem_start;
273 info->apertures->ranges[0].size = size_remap;
274
275 if (nowc)
276 info->screen_base = ioremap(efifb_fix.smem_start, efifb_fix.smem_len);
277 else
278 info->screen_base = ioremap_wc(efifb_fix.smem_start, efifb_fix.smem_len);
279 if (!info->screen_base) {
280 pr_err("efifb: abort, cannot ioremap video memory 0x%x @ 0x%lx\n",
281 efifb_fix.smem_len, efifb_fix.smem_start);
282 err = -EIO;
283 goto err_release_fb;
284 }
285
286 pr_info("efifb: framebuffer at 0x%lx, using %dk, total %dk\n",
287 efifb_fix.smem_start, size_remap/1024, size_total/1024);
288 pr_info("efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
289 efifb_defined.xres, efifb_defined.yres,
290 efifb_defined.bits_per_pixel, efifb_fix.line_length,
291 screen_info.pages);
292
293 efifb_defined.xres_virtual = efifb_defined.xres;
294 efifb_defined.yres_virtual = efifb_fix.smem_len /
295 efifb_fix.line_length;
296 pr_info("efifb: scrolling: redraw\n");
297 efifb_defined.yres_virtual = efifb_defined.yres;
298
299 /* some dummy values for timing to make fbset happy */
300 efifb_defined.pixclock = 10000000 / efifb_defined.xres *
301 1000 / efifb_defined.yres;
302 efifb_defined.left_margin = (efifb_defined.xres / 8) & 0xf8;
303 efifb_defined.hsync_len = (efifb_defined.xres / 8) & 0xf8;
304
305 efifb_defined.red.offset = screen_info.red_pos;
306 efifb_defined.red.length = screen_info.red_size;
307 efifb_defined.green.offset = screen_info.green_pos;
308 efifb_defined.green.length = screen_info.green_size;
309 efifb_defined.blue.offset = screen_info.blue_pos;
310 efifb_defined.blue.length = screen_info.blue_size;
311 efifb_defined.transp.offset = screen_info.rsvd_pos;
312 efifb_defined.transp.length = screen_info.rsvd_size;
313
314 pr_info("efifb: %s: "
315 "size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
316 "Truecolor",
317 screen_info.rsvd_size,
318 screen_info.red_size,
319 screen_info.green_size,
320 screen_info.blue_size,
321 screen_info.rsvd_pos,
322 screen_info.red_pos,
323 screen_info.green_pos,
324 screen_info.blue_pos);
325
326 efifb_fix.ypanstep = 0;
327 efifb_fix.ywrapstep = 0;
328
329 info->fbops = &efifb_ops;
330 info->var = efifb_defined;
331 info->fix = efifb_fix;
332 info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
333
334 orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
335 efifb_defined.yres);
336 switch (orientation) {
337 default:
338 info->fbcon_rotate_hint = FB_ROTATE_UR;
339 break;
> 340 case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
341 info->fbcon_rotate_hint = FB_ROTATE_UD;
342 break;
> 343 case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
344 info->fbcon_rotate_hint = FB_ROTATE_CCW;
345 break;
> 346 case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
347 info->fbcon_rotate_hint = FB_ROTATE_CW;
348 break;
349 }
350
351 err = sysfs_create_groups(&dev->dev.kobj, efifb_groups);
352 if (err) {
353 pr_err("efifb: cannot add sysfs attrs\n");
354 goto err_unmap;
355 }
356 err = fb_alloc_cmap(&info->cmap, 256, 0);
357 if (err < 0) {
358 pr_err("efifb: cannot allocate colormap\n");
359 goto err_groups;
360 }
361 err = register_framebuffer(info);
362 if (err < 0) {
363 pr_err("efifb: cannot register framebuffer\n");
364 goto err_fb_dealoc;
365 }
366 fb_info(info, "%s frame buffer device\n", info->fix.id);
367 return 0;
368
369 err_fb_dealoc:
370 fb_dealloc_cmap(&info->cmap);
371 err_groups:
372 sysfs_remove_groups(&dev->dev.kobj, efifb_groups);
373 err_unmap:
374 iounmap(info->screen_base);
375 err_release_fb:
376 framebuffer_release(info);
377 err_release_mem:
378 if (request_mem_succeeded)
379 release_mem_region(efifb_fix.smem_start, size_total);
380 return err;
381 }
382
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: kbuild test robot <hidden> Date: 2017-11-28 16:48:10
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171128-225025
config: i386-randconfig-x074-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/intel_dsi.c: In function 'intel_dsi_get_panel_orientation':
quoted
drivers/gpu/drm/i915/intel_dsi.c:1672:21: error: storage size of 'plane' isn't known
From: kbuild test robot <hidden> Date: 2017-11-28 20:46:17
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171128-225025
config: x86_64-randconfig-x012-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/intel_dsi.c: In function 'intel_dsi_get_panel_orientation':
drivers/gpu/drm/i915/intel_dsi.c:1672:21: error: storage size of 'plane' isn't known
enum i9xx_plane_id plane;
^~~~~
From: Daniel Vetter <hidden> Date: 2017-11-29 09:59:14
On Tue, Nov 28, 2017 at 02:36:09PM +0100, Hans de Goede wrote:
Hi,
On 28-11-17 11:27, Daniel Vetter wrote:
quoted
On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote:
quoted
Hi All,
Here is v6 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).
Bartlomiej, can we please have your Acked-by for merging patches 1,
6 and 7 through the drm tree?
New in v6:
-Fix / reference kernel-doc comments
-Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
-Move i915 dsi hardware rotation state read-out to intel_dsi_init()
New in v5:
-Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
-drm_fb_helper: Only use hardware (crtc primary plane) rotation for
180 degrees for now as 9-/270 degrees rotation requires special handling
New in v4:
-Fix drm_fb_helper code setting an invalid rotation value on the primary
plane of disabled/unused crtcs (caught by Fi.CI)
New in v3:
-As requested by Daniel v3 moves the quirks over from the fbdev
subsys to the drm subsys. I've done this by simpy starting with a copy of
the quirk table and eventually removing the fbdev version.
The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
discussed previously the plan is to merge all 7 patches through the
drm tree.
I think from the drm and i915 side of things this all looks ready (well
pls double-check that CI also approves before merging).
The CI says state is warning, see:
https://patchwork.freedesktop.org/series/32447/
and specifically:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7290/shards.html
Which I find hard to read as I see no tests going to orange, only
3 tests moving to red, which AFAICT is failed. Clicking on the tests
link to get history all 3 tests seem to fail in the same way quite
often (2 out of 3) or somewhat often (the last one). Also the failures
seem unrelated to my changes
So how do I deal with this, resend v7 to get CI to run again and hope
I get a success result for all tests this time ?
-rc1 set CI on fire, we had to entirely disable reporting shard results.
Note that in the mail report you get annotations of known bugs, and the
skip<->pass flip-floppers are fallout from CI being on fire.
So looks all good to go.
-Daniel
quoted
Just needs an ack/review from Bart, and then it's probably simplest if you
merge it all through drm-misc - the i915 side is tiny.
Ok, I will wait for an Ack from Bart and then merge this through drm-misc,
thank you for the review.
Regards,
Hans